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From the Editor 


With INTEROP 92 Spring just over, it is time to get the June issue 
out the door, so the report from the show will have to wait for a 
while. The only INTEROP related article you'll find in this issue is a 
look back to last fall: Brent Chapman gives us an insideyr’s look at 
the building and management of the show network (page 18). 


First, another installment in our Components of OSI series. This 
time we examine the standard for the Remote Procedure Call Ser- 
vice, currently under ballot for progression to Draft International 
Standard (DIS). The article is by Alan Turner from Battelle’s Pacific 
Northwest Laboratory. 


For the last year or so, we’ve been running articles about “neat new 
stuff’—applications developed for use in the Internet (or in private 
internets) that go far beyond the basic functionality of e-mail, file 
transfer and remote login. A very recent addition to this collection of 
new applications was demonstrated at the San Diego IETF meeting 
earlier this year. Live audio from the IETF site was “audiocast” 
using IP multicast packet audio over the Internet to participants at 
20 sites on three continents spanning 16 timezones. Steve Casner 
and Steve Deering describe the setup in an article on page 10. We 
have more articles coming on new Internet applications. Stay tuned 
for Prospero, Gopher and World Wide Web in future issues. 


SNMP has clearly become the network management protocol of 
choice in the industry. James R. Davin, the Area Director for net- 
work management in the IETF, describes how the Internet manage- 
ment framework allows for an evolution, and how you can take part 
in that process. 


While ConneXions does not normally engage in product comparison 
or review, it is an “interoperability report.” Therefore, when I came 
across the Serial Line Internet Protocol (SLIP) interoperability study 
performed by Richard Coop from the University of Hull, I decided to 
ask for an article. The text illustrates some very important lessons 
about the interworking between different implementations of the 
same basic protocol, and is based upon research performed for the 
UK Internet Consortium (UKIC). The results were first presented at 
a “mini-INTEROP” hosted by UKIC in February of this year. 


The Great OSI Debate drew a large crowd at INTEROP 92 Spring, 
and reactions to it and my opinion piece in the May issue is starting 
to arrive. This month we bring you the updated version of Dick 
desJardins’ argument, as well as a few letters to the Editor on the 
same topic. Keep your letters coming on this and any other subject. 


Another Special Issue of ConneXions on electronic mail and directory 
services is taking shape and will most likely be released in August. 
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Components of OSI: 
The Remote Procedure Call (RPC) Service 


by Alan E. Turner II, Battelle—Pacific Northwest Laboratory 


Distributed computing using the client-server model has become 
increasingly common. Client-server computing distributes the proces- 
sing of an application between two or more systems whose interaction 
is coordinated with function-specific protocols. 


Remote Procedure Call (RPC) is a general purpose mechanism to 
support distributed computing [1]. Rather than supporting a specific 
function (e.g., window systems, database access), RPC systems allow 
the development of distributed applications which support whatever 
functions their designers envision. 


RPC systems operate by extending local procedure calls to operate 
between processes on separate networked systems. The effect is to 
hide the complexity of operating in a network environment (e.g., 
protocols, error recovery, data representation, addressing) from the 
application developer and replace it with the illusion that a distri- 
buted system is local. The client and server interact using what 
appear to be local procedure calls. 


Several widely used commercial systems that use RPC are currently 
on the market (e.g., Netwise’s RPCtool, OSF’s DCE, and Sun’s ONC), 


Existing OSI protocols offer most of the support needed to provide an 
RPC service. ISODE, a publicly available implementation of OSI, con- 
tains an “application cookbook” [2] which delivers RPC capabilities by 
building on the available OSI services. However, if different imple- 
mentations of RPC were to interoperate a new application layer 
standard was required. 


This article describes the OSI RPC as specified in the Committee 
Draft standard [3] currently under ballot for progression to Draft 
International Standard (DIS). The article takes a brief tour through 
the standard, outlining its purpose, describing many of its key 
features, and providing examples of its usage. 


The OSI RPC standard has been written to ensure the future inter- 
operability of distributed applications that use RPC. It is also hoped 
that providing a general purpose mechanism in OSI will reduce the 
need for application-specific protocols. 


RPC is unusual among OSI application layer standards in two signifi- 
cant ways. It is intended to be used directly by application program- 
mers, and it does not specify a complete protocol but rather a basic 
protocol framework, a language (the interface definition notation) for 
specifying interfaces, and rules to convert a specific interface to a 
complete protocol. 


The interaction model defines the style of interactions supported by 
OSI RPC by relating its concepts (including interface, binding, calls, 
context, terminations, and cancels) to those of programming environ- 
ments. These concepts are discussed in the following paragraphs. 
However, the model should be interpreted at an abstract level and is 
independent of any particular implementation technique, program- 
ming language, or communications protocol. 


Interactions are defined without reference to, and are independent of: 
The location of the procedures; the data communications services 
used; the programming languages used to produce the procedures; the 
data representation used by programming languages or systems. 
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Interfaces and bindings 


Call semantics 


Persistent context 


OSI RPC groups a set of procedures into an interface. The interface 
specifies the “signature” of each procedure: the procedure name, the 
number, types and directions of its parameters, and the terminations 
and types returned. 


An interface instance is one instance of a server, offering an interface. 
Clients and servers are bound together at execution-time, the OSI 
RPC identifies each particular binding using what is traditionally 
called a binding handle. Each server may be bound to many clients 
and each client may also be bound to many servers. Calls to the same 
remote procedure using the same binding will always result in exe- 
cution of the same physical procedure. A binding’s lifetime is appli- 
cation-dependent. 


A binding must exist before any remote procedure calls can occur. The 
interface definition contains an interface identifier which can be used 
by the client to locate and bind with a server. 


All OSI RPC interactions consist of calling and executing procedures. 
Every call always consists of the following sequence of events (which 
may be incomplete if a failure or cancel occurs): 


° The call occurring at the calling procedure; 

e The call arriving at the called procedure; 

e Execution of the called procedure; 

e The return occurring at the called procedure; 
e The return arriving at the calling procedure. 


Multiple OSI RPC interactions can occur at the same time. The exe- 
cution of a called procedure might include another remote procedure 
call back to its caller (a call-back ). At any given time, there may be 
multiple concurrent procedure calls outstanding. The concurrency and 
synchronization mechanisms used in applications is not specified or 
restricted by the RPC standard. Systems which support parallelism 
(e.g., with fork and join or light weight threads) will not be restricted 
in their use of the OSI RPC service. 


OSI RPC supports “at-most-once” call semantics. In the case of a 
successful return, the caller knows that the remote procedure has 
been executed exactly once; however, in the case of a failure return, 
the calling procedure may not be able to determine whether the 
remote procedure was executed. 


It is possible for an application to combine the services of RPC and 
OSI transaction processing [4] to achieve exactly-once semantics. The 
application can then ensure that a remote procedure has been exe- 
cuted exactly once or never with no possibility of partial execution. 


All information communicated between the calling and called proce- 
dures is explicitly contained in parameters. 


The client and server may have relationships whose durations are 
longer than a single call. These relationships and their duration are 
application-specific. In these cases, the server is aware of the client 
and may explicitly maintain execution context (e.g., state information) 
on its behalf. 


Applications typically use context handles to identify the context 
maintained between calls. A handle is generated by the application to 
identify some part of the context; its meaning and lifetime are deter- 
mined by the application. Handles may be passed between a client 
and server as parameters of RPCs. 

l continued on next page 
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The Remote Procedure Call (continued) 


For a distributed application to use context handles, the client must 
be able to access the same server across successive calls. The OSI 
RPC binding mechanism allows this. 


The OSI RPC standard does not manage context handles. However, it 
is possible for vendors to use the extension mechanism to identify 
parameters that represent context information and then manage 
them through local means. 


A termination is the response generated by a particular call. One 
termination that is always possible is the “normal” termination—the 
successful completing of a procedure and return of its parameters. 
Since remote procedure calls are subject to sources of failure not 
present in the local case, additional terminations have been defined. 
OSI RPC supports three classes of terminations: 


e Application-specific terminations are defined in the interface 
definition. This includes both the “normal” termination and any 
additional terminations which are specified. 


e RPC-specific terminations are defined in the standard. These ad- 
dress problems such as parameter errors, insufficient resources, 
cancellation of the remote procedure call, and network errors. 


e System-specific terminations are defined elsewhere, for example 
by system implementors. 


OSI RPC includes a cancel mechanism which can be used to request 
the cancellation of an outstanding remote procedure call. If a proce- 
dure call is outstanding when a local cancel (e.g., a Control-C) is 
received by the caller, the cancel can be propagated to the callee. 


The OSI RPC’s Interface Definition Notation is the language used to 
write an interface definition, which describes the interface between a 
client and a server. Since the interface definition is the user’s inter- 
face to the RPC services it has been designed to be familiar to appli- 
cation programmers, easy to use, and as expressive as most proce- 
dural programming languages. 


Interface definitions can be exchanged between systems and proces- 
sed for use in supporting a distributed application. The standard does 
not constrain how an implementation should process an interface 
definition. Traditionally however, interface definitions are processed 
by “stub compilers” which produce code (that appears to the appli- 
cation to be the procedures specified in the interface definition) which 
is linked with the client and server portions of the application. Inter- 
face definitions can import constant, type, and procedure definitions 
from another interface definition to facilitate modular development. 


An interface definition will generally contain several procedure 
declarations; some of these procedures are located on the client and 
others on the server. Each procedure declaration contains a list of 
parameters and their types and attributes, an optional return para- 
meter, and an optional list of parameterized exceptions. Parameters 
each have a direction (in, out, or inout) which determines if the 
parameter must be transmitted on call, return, or both. 


An interface definition can contain primitive data types (integer, real, 
character, boolean, enumerated, procedure, and octet), generated data 
types (record, choice, array, and typed pointer), and combinations of 
the two (e.g., a pointer to procedure or an array of records). In 
addition, the interface definition may define a data type and then use 
its name as a new type. 


Example 


Communication Model 
Service and Protocol 
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The sample interface definition below illustrates some of the expres- 
sive power of the interface definition notation. For the purpose of 
illustration, the identification of interfaces has been simplified to a 
simple label, in this case “Example.” 


The import mechanism is used to obtain two symbols, “typel” and 
“type2,” from the interface “External.” “External” (not shown here) 
defines these symbols as the names of types. 


The first type definition defines a record type named “recl.” This 
record contains an integer and a dynamic array whose size will be 
determined at call time. The second type definition defines an 
enumerated type named “enum1.” 


Two constant values (“startint” and “endint”) are defined next. 


Procedure “foo,” which is located on the server, has four parameters. 
Parameter “c” is an example of a multi-dimensional array type with 
dynamic bounds in the first dimension “a..b.” The actual bounds are 
determined at the time of the call by examining parameters “a” and 
“b.” Parameter “d” is an example of a typed pointer. 


Procedure “bar,” which is located on the client, has three parameters 
and allows a return value. Parameter “h” is an example of the choice 
type. Choice types always include a discriminant, in this case “g,” 
whose value is used at call time to determine which alternative field 
is actually in use (“p” if g is between 1 and 5, “q” if g is between 6 and 
9, or “r” otherwise). 


interface “Example” 
begin 
imports typel, type2 from “External”; 
type recl = record of (flda: integer, 
fldb: array(*) of character ); 
type enuml = enumerated ( red, blue, green ); 
value startint : integer = 10; 
value endint : integer = 20; 
procedure foo ( 


in a: integer, 

in b: integer, 

inout c: array( a..b ,startint..endint) of typel, 
in d: pointer to recl 


); 
[ client ] procedure bar ( 
out Le typez, 


in g: integer, 

iñ ht Gheace ( ¢ ) of ( 
Select. ( Is-5 Jp: real, 
select ( 6..9 )q: boolean, 
default r: enuml 


) 
) returns( s: real ); 
end 


An earlier article in this series [5] described the OSI Application 
Layer Structure (ALS) and Application Service Elements (ASEs). The 
recently extended ALS (or XALS) [6] provides a recursive structure 
which supports the inheritance of services within the application 
layer. An XALS Application Service Object (ASO) may contain a set of 
ASEs or ASOs or both. OSI RPC is the first standard to utilize KALS 
concepts in its specification. 
continued on next page 
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The Remote Procedure Call (continued) 


The OSI RPC standard uses five application layer components to 
perform remote procedure calls. These components are the User ASO, 
the Signature ASE, the Basic RPC ASO, the ROSE ASE, and the RPC 
Association Provider ASO. These elements are configured like this: 


User ASO 


Signature ASE 


Basic RPC ASO 
RPC Association 
ROSE ASE Provider ASO 


Note that OSI models are not intended to represent implementation 
architectures and are never subject to conformance. 


The User ASO is the component directly accessible to the application. 
It provides a “custom” set of services which appear to be the proce- 
dures defined in the interface definition. Its services include invoking 
specific procedures, returning their results, and reporting errors. In 
addition it provides the RPC cancel services to the application. The 
primary function of this ASO is to coordinate the operation of the 
Signature ASE and the Basic RPC ASO. 


The Signature ASE is “custom” built for a specific interface definition 
by applying rules contained in the standard. The Signature ASE 
understands each procedure and its parameters and offers services to 
invoke, return, and report errors. The ASE produces an “operation 
number” and “argument data” for each invoke. 


The Basic RPC ASO provides RPC services which do not vary with the 
application. This ASO views procedures as being numbered “oper- 
ations” which each take a single chunk of “argument data.” The ser- 
vices provided are to invoke operations, return operation results, 
cancel operations, and to report and manage errors. 


The ROSE ASE [7] produces simple protocol to request a remote oper- 
ation and return the operation’s results or errors. The Basic RPC ASO 
uses ROSE to package its “operation numbers” and “argument data” 
into protocol for the invokes and returns. 


The RPC association provider ASO provides communications to trans- 
fer information between client and server. The Basic RPC ASO uses 
this ASO to transfer the protocol generated by ROSE. 


OSI application layer entities communicate over “associations.” The 
RPC association provider ASO (AP-ASO) controls how these associ- 
ations are established, used, and released. 


Designers of the OSI RPC standard considered many alternatives for 
managing associations: 


e Using connection-oriented (CO-mode) associations whose duration 
would be a single call. 


e Using, or sharing, connection-oriented associations whose dur- 
ation might be several calls. 


e Using connection-less (CL-mode) associations (whose durations by 
definition are always a single message). 


Each alternative has differing strengths and weaknesses; each could 
be the “best” given the right application and environment. In fact, all 
three schemes have been used by existing RPC systems. 


Data Representation 


Future 


Conclusion 
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It is possible to implement any of the schemes by designing an appro- 
priate AP-ASO. However, RPC implementations which use different 
AP-ASOs may not interoperate. 


The standard currently specifies an AP-ASO which manages CO- 
mode associations with a duration of one call. The service is a “one- 
shot” which bundles together the association establishment, call, 
return, and association release. This allows implementations to ap- 
proach the CL-mode style in performance for simple client-server 
relationships while avoiding the complexity of coordinating the CL- 
mode associations. 


The standard also contains an optional alternate AP-ASO which 
manages CO-mode associations with a long duration. This ASO would 
offer better performance for applications which perform “bursts” of 
procedure calls or which use other OSI services which also maintain 
associations. 


Since OSI RPC is an application layer standard it is only indirectly 
concerned with data representation. These concerns are handled by 
the presentation layer and through the use of Abstract Syntax 
Notation One (ASN.1), both summarized in earlier articles in this 
series [8, 9]. 


It is the responsibility of the presentation layer to “negotiate” the 
actual data representations used to exchange information. To simpli- 
fy, all data is described using the abstract notation and represented 
by applying particular encoding rules to the local data so described. 


There has been concern that any RPC which uses the OSI Basic 
Encoding Rules (BER) will be inefficient. The newer OSI encoding 
rules (e.g., light weight encoding rules, packed encoding rules) can be 
implemented more efficiently than BER and will no doubt be used to 
support RPC. 


Other encoding rules are possible (and can be defined by groups other 
than ISO/CCITT) which can handle the data representation problem 
in whatever way their designers desire, including every method in use 
by current RPC systems. 


Two non-OSI international standard projects, together known as the 
Common Language Independent (CLI) work, are addressing the prob- 
lems of language independent procedure calls [10] and data types 
[11]. CLI will enable conforming programming languages to partici- 
pate in a multi-language environment by being able to consistently 
call each other and understand the same data types. 


The procedure call model and data types of CLI and OSI RPC are 
identical. As language groups complete their procedure call and data 
type mappings for CLI, all of that work will be directly applicable to 
OSI RPC; this will save considerable time and expense. 


Using RPC and CLI it will be possible for application developers to 
call a routine without knowing what language the routine was written 
in, what system the routine executes on, or even if the routine is local 
or remote. 


Although the OSI RPC standard is complex it is also designed to be 
easy to use by application programmers and to be efficiently imple- 
mentable. When the standard reaches Draft International Standard 
(DIS) level it will be technically stable, a key factor in implementation 
decisions. As with most standards, the market will then decide what 
happens next. 
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References 


The Remote Procedure Call (continued) 


By providing the application programmer with a sophisticated tool, 
OSI RPC reduces the difficulty of creating distributed applications. A 
significant barrier to network usage (programming complexity) is 
reduced; the need to create and support more protocols is decreased; 
and most significantly, the opportunity to economically realize new 
services tailored to specific problems is increased. 
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“Components of OSI” in ConneXions 


In an attempt to explain the Open Systems Interconnection (OSI) 
model, promulgated by the International Organization for Standard- 
ization (ISO) and the Consultative Committee for Telephone and 
Telegraph (CCITT), ConneXions has been running a number of 
articles under the heading “Components of OSI.” Here is a list of 
them: 


Integrated Services Digital Network (ISDN) April 1989 
X.400 Message Handling System May 1989 
X.500 Directory Services June 1989 
The Transport Layer July 1989 
Routing overview August 1989 
IS-IS Intra-Domain Routing August 1989 
ES-IS Routing August 1989 
The Session Service September 1989 
Connectionless Network Protocol (CLNP) October 1989 
The Presentation Layer November 1989 
A taxonomy of the players December 1989 
The Application Layer Structure January 1990 
File Transfer, Access, and Management (FTAM) April 1990 
The Security Architecture August 1990 
Group Communication September 1990 
X.25—the Network, Data Link, & Physical Layers December 1990 
The Virtual Terminal ASE January 1991 
Systems Management April 1991 
CO/CL Interworking May 1991 
Open/Office Document Architecture (ODA) August 1991 
Abstract Syntax Notation One (ASN.1) January 1992 
Broadband ISDN April 1992 
Synchronous Optical Network (SONET) April 1992 
Asynchronous Transfer Mode (ATM) April 1992 
Inter-Domain Routing Protocol (IDRP) May 1992 
The Remote Procedure Call (RPC) Service June 1992 
OSI Conformance Testing Coming soon 


Also note that FDDI, while not published under the same heading, is 
also an ISO protocol and should be considered part of the set. You'll 
find articles on FDDI in the October 1990, September 1991, and Octo- 
ber 1991 issues. There are still more articles to come in this series, so 
stay tuned! All back issue are available for purchase. To order a back 
issue, or for more information contact: 


ConneXions—The Interoperability Report 

480 San Antonio Road, Suite 100 

Mountain View, CA 94040-1219 

USA 

Phone: +1 415-941-3399 or 1-800-INTEROP (Toll-free in the USA) 
Fax: +1 415-949-1779 

E-mail: connexions@interop.com 


10 


CONNEXIONS 


Introduction 


What was required 


First IETF Internet Audiocast 
by Steves Casner and Deering 


The March Internet Engineering Task Force IETF) meeting in San 
Diego was an exciting one for those interested in teleconferencing. In 
addition to several sessions on teleconferencing topics, we managed to 
pull off a “wild idea” suggested by Allison Mankin from MITRE: live 
audio from the IETF site was “audiocast” using IP multicast packet 
audio over the Internet to participants at 20 sites on three continents 
spanning 16 timezones. 


The audiocast included all the general sessions plus one session of the 
Teleconferencing Architecture BOF and the three sessions of the 
Audio/Video Transport working group. Unlike a radio broadcast, the 
remote participants could talk back as well, as demonstrated during a 
brief technical presentation on the experiment. Though there were 
some problems, we knew this experiment was a success when, during 
the working group sessions, remote participants were able to ask 
cogent questions and engage in the discussion. 


This event was a pilot experiment that we hope will be expanded at 
future IETF meetings to reach more destinations and to include video, 
images and “shared whiteboards” along with audio. This is a step 
toward a more distributed IETF, a goal Dave Farber and Jack 
Haverty challenged the IETF community to pursue during a discus- 
sion on the IETF mailing list last fall. This was also a demonstration 
of technology developed and tested in the DARTnet research testbed 
network sponsored by DARPA. 


Two key elements were required to put the audiocast together: 


e Hardware and software to generate and receive audio packets at 
the endpoints. 


e IP multicast routing [1] to replicate the packets efficiently for 
distribution to a large number of recipients. 


Audio hardware is now built into many workstations, such as Sun and 
NeXT, and is ready for deployment of software. To simplify this pilot 
experiment, we kept to the same hardware and software already tes- 
ted in DARTnet. Of four interoperable packet audio programs, three 
run on Sparcstations (VT from ISI, vat from Lawrence Berkeley Labo- 
ratory (LBL), and NEVOT from University of Massachusetts) and one 
runs on a 386 PC plus audio card (from MIT). 


At IETF and most of the remote sites, we ran vat, the Visual Audio 
Tool, written by Van Jacobson and Steve McCanne. In an X window, 
vat displays VU meters and volume control sliders for the microphone 
and speaker levels plus a status display identifying the ithe ain 
in the conference. 


Conference Hasts mute both 


muste | route 


Steve Casner (ISI) 


Steve Deering (PARC) G2 


Yan Jacobson (LBL) 


LBL Visual Audio Tool v1.19beta , 


Figure 1: Image of a vat window 


Voice data rates 


Protocols 


NVP-II 
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Behind the user interface, there are severai important functions 
required to process audio packets: 


e Silence/sound detection to avoid sending packets during silence, 
preferably with a dynamic threshold to accommodate varying 
levels of background noise. 


e An adaptive playout delay to achieve continuous playback even 
though network delays vary. For multimedia systems, playout 
delays are also used to achieve synchronization. 


e Resequencing of out-of-order packets and filtering of duplicate 
packets within the playout delay buffer. 


e Mixing of audio sample streams when packets arrive from mul- 
tiple sites at the same time. 


e A means to suppress acoustic feedback from the loudspeaker to 
the microphone that produces an echo at the far end (headphones 
are one solution, half-duplex speakerphone mode is another). 


For this audiocast, we used the 64Kbps PCM audio produced by the 
Sparcstation’s /dev/audio device directly. Each packet contains 180 
PCM voice samples, corresponding to an interval of 22.5 milliseconds 
and a rate of 44.4 packets per second. As shown in Figure 2, the 
packet overhead is 32 bytes not counting any MAC header, resulting 
in a peak overall data rate of 75Kbps. However, since no packets are 
transmitted during silence, the average data rate is less. As software 
bandwidth compression algorithms are implemented in packet audio 
programs in the future, it will be possible to reduce the data rate for 
operation over slower network links. 


8 4 


20 180 
(octets) 


Figure 2: Audio Packet Format 


Note that packet audio is transported by UDP rather than TCP, for 
two reasons. First, TCP’s reliability and flow control mechanisms 
aren’t appropriate. Occasional packet loss causes only a small and 
acceptable reduction in audio quality, while allowing time for retrans- 
mission would require a longer playback delay, making interactive 
conversation more difficult. Flow control is not required because 
packets are generated at a regular rate and must be communicated 
and consumed at that rate. (Some systems may allow the data rate to 
be adjusted to compensate for network load.) 


The second reason for choosing UDP is that it works well with IP 
multicast to reach many destinations, while TCP is limited (so far, at 
least) to point-to-point connections. 


UDP lacks two functions of TCP that are needed: packet reordering 
and duplicate filtering. We add another protocol layer to provide these 
functions. As an interim convention, we use the data packet header 
from the Network Voice Protocol (NVP-II) [2], as shown in Figure 3 on 
the next page. For this version of PCM audio, the timestamp field 
increments every 22.5 millisecond packet interval, including during 
silence when no packets are transmitted. 
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This provides sequencing and duplicate detection within a packet 
lifetime of about 20 seconds. The separate sequence number incre- 
ments once per packet transmitted, enabling the detection of lost 
packets versus packets not transmitted during silence. 


| Seq # | Timestamp | Chksum | OptLen | 
6 10 8 8 


<——_—_— _ 382 bits ———______» 


Figure 3: NVP Header Format 


The NVP header is efficient (only 32 bits), but that makes some of the 
fields too small to support current requirements. It is in the charter of 
the Audio/Video Transport working group to devise one or more 
replacement protocols for packet audio, video and perhaps other 
media. At the San Diego IETF, a minimal strawman protocol was pro- 
posed and we discussed what functions should be added to it. Send a 
message to rem-conf-request@es.net to join the discussion. 


Besides end-system hardware and software for packet audio, the 
second key element required for the IETF audiocast was IP multi- 
casting. For a large conference like the audiocast, the bandwidth and 
processing required for the source host to send a separate copy of each 
packet to each destination would be prohibitive. With IP multicast 
extensions implemented in the participating hosts and routers, the 
source can send a single copy of each packet which is then replicated 
as needed at each branching point on the logical tree reaching out to 
the destinations. 


Unfortunately, few routers in the Internet implement IP multicast 
routing yet. Fortunately, the experimental DARTnet routers do, using 
the Distance Vector Multicast Routing Protocol (DVMRP) implemen- 
ted by Steve Deering in the mrouted daemon plus kernel extensions. 
This makes it easy for us to hold DARTnet experimenters’ tele- 
conferences every week using packet audio and video. DARTnet was 
also available for use as a transcontinental multicast backbone for the 
audiocast. But just as we need to reach some DARTnet experimenters 
not directly connected to DARTnet, we needed to extend past 
DARTnet to the audiocast sites. 


In order to support multicasting among subnets that are separated by 
(unicast) routers that do not support IP multicasting, mrouted in- 
cludes support for “tunnels,” which are virtual point-to-point links 
between pairs of mrouteds located anywhere in the Internet. To trans- 
mit a multicast packet through a tunnel, a multicast router modifies 
the packet by appending an IP Loose Source Route option to the 
packet’s IP header. The multicast destination address is moved into 
the source route, and the unicast address of the router at the far end 
of the tunnel is placed in the IP Destination Address field. Thus, the 
packet looks like a normal unicast packet to the routers and subnets 
along the path of the tunnel. The router at the far end of the tunnel 
restores the original multicast destination address and deletes the 
source route before forwarding the packet. 


For DARTnet teleconferences, we need only a few tunnels extending 
from DARTnet nodes to individual sites, but for the audiocast we 
needed to expand this idea to a whole network of tunnel links with 
DARTnet as a backbone. That network, shown in Figure 4, set a 
record as the largest IP multicast network to date, with 34 routers 
linking 40 subnets. 
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Figure 4: Multicast Router Topology for IETF Audiocast 3/92 


The solid lines near the top of the graph indicate physical DARTnet 
links. The other lines are all multicast tunnels (virtual links) over a 
variety of Internet paths including the T3 NSFNET and international 
links. By assigning different metrics to different links, we established 
primary tunnels (dashed lines) and backup tunnels (dotted lines) to be 
used in case of failure in the primary tunnels or DARTnet lines. 


What we learned The IETF audiocast was a valuable learning experience! Van Jacob- 
son produced five new versions of vat during IETF week, adding new 
features to improve performance. For most of the audiocast, listener 
reports of the sound quality ranged, over time and place, from “very 
clear” to “intelligible.” Listeners were able to comprehend most of 
what was said, but there were several factors that caused dropouts in 
the playback. 


The most obvious and expected cause of dropouts was that competing 
traffic would cause variance in the transit delay, especially on longer 
paths. To compensate, Van made improvements in vat’s delay adap- 
tation algorithm and added a “lecture mode” that lets the playout 
delay remain large to minimize the number of packets declared late, 
for use during lectures when reduced interactivity is acceptable. 


Audio pickup The second problem had nothing to do with packets, but with acoustic 
audio pickup and silence suppression. During the Teleconferencing 
Architecture BOF session, we did not have a lapel microphone and 
attempted to pick up the presenters with a table microphone. The 
signal-to-noise ratio was too low because the presenters were too far 
from the microphone and there was too much ambient noise in a room 
divided by movable walls. A related problem was that, even when the 
speaker used a lapel microphone, comments from the audience were 
not picked up well enough by the room microphones and were sup- 
pressed as silence. Remote listeners heard the presenter’s punch line 
but didn’t hear the set-up comment from the audience. This was frust- 
rating. To avoid this problem, Van added a control in vat to turn off 
silence suppression for use during presentations. 
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On the other hand, disabling silence suppression may exacerbate net- 
work loading and the resulting dropouts. Simon Hackett postulated 
that presenting a continuous load makes a non-trivial increase in the 
average bandwidth and eliminates the gaps that may give routers a 
chance to empty their queues. In addition, the packet audio receivers 
generally make playout delay adjustments during silence intervals, so 
drift between the sending and receiving clocks must be accommodated 
in some other way for continuous transmission. 


The third cause of dropouts was a persistent estimated 10-20% pac- 
ket loss that we could not find nor explain. This loss was not evident 
in tests with ping and traceroute. Apparently there was no loss across 
the local T1 line connecting the source host in the main ballroom to 
the terminal room where another host running vat monitored the 
signal. We believe the loss occurred somewhere between the IETF 
terminal room and DARTnet, perhaps between IETF and the San 
Diego Supercomputer Center (SDSC). Even though a terminal room 
full of nerds banging on keyboards amounts to quite a few packets per 
second, that should not have created enough congestion to cause 
persistent, low-level packet loss. 


One potential explanation would be that the multicast tunnel packets 
use the IP Loose Source Route option, which diverts those packets to a 
slower processing path in some router architectures. However, we also 
tested with some source-routed test traffic at rates similar to the 
audio and did not see the same loss. In any case, there are plans to 
modify mrouted to encapsulate in a separate IP header rather than 
use the source route option. 


We would likely have been able to find the cause of the packet loss if 
we had enough time to investigate fully, but we also had real IETF 
business to do! Clearly we need better measurement tools and proce- 
dures to accelerate the process. It would also have been very helpful if 
we had some way to monitor reception at a distance so we could tell 
when there are problems without the users having to contact us. 


While the audiocast alone was interesting to the remote participants, 
in part because of its novelty, it is clear that we need to provide some 
of the visual content of the presentations as well. As one experiment, 
Ralph Droms made available via FTP the PostScript and ASCII ver- 
sions of the transparencies for his talk on the Dynamic Host Con- 
figuration Protocol. The response was very positive. 


Over DARTnet we regularly send packet video as well as packet 
audio. The data rate we typically use is only 128Kbps, twice the audio 
rate. It should be possible to implement software to decode that video 
and display it in an X window. This is under investigation at ISI. 
Other implementations are also feasible, for example some software 
encoding of video grabbed at a slow frame rate from a device such as 
the Sun VideoPix card. 


Video of the presentations would give a better sense of what was 
happening, but video does not have adequate resolution to show slides 
very well. For that, an automated slide presentation tool would be 
preferable, working from on-line source material or an on-site scan- 
ner. To generalize further for interactive working group discussions 
as well as presentations, a “shared whiteboard” onto which slides can 
be posted would be even better. Several research projects are working 
on such tools. Future IETF meetings would provide an opportunity for 
a trial by fire for these tools. 


Scaling up to 
widespread use 
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Perhaps the biggest impediment to expanded services will not be 
network bandwidth or implementation of new tools, but logistics at 
the IETF site. We had enough trouble this first time trying to figure 
out how to connect into the ballroom audio system in such a way that 
a moderator could preview questions from remote sites before 
disturbing the local participants. Video cameras and people to operate 
them will add another logistical dimension the IETF Secretariat may 
be reluctant to tackle, not to mention the additional expense. 


Yet another level of complexity would be introduced if multiple 
working group meetings are to be teleconferences. Especially for the 
larger working groups, room acoustics would be a problem, both for 
picking up the voices of all participants and to play the sound from 
the remote end at sufficient volume and still cancel the echo caused 
by the microphones picking up that sound. Also, the resolution of 
compressed video is not sufficient for more than about 6 people. Yes, 
rooms can be outfitted with equipment and video production person- 
nel to handle these problems, but the cost is substantial. Meeting 
sites with a video-equipped auditorium and 20 breakout rooms 
equipped for videoconferencing are probably rare. 


Network connectivity within the site is another issue. At San Diego, 
we were unable to get twisted pair Ethernet to reach between build- 
ings at the hotel over some crusty old wiring passing through the 
damp pool filter room. We had to back off to more bulky T1 equip- 
ment, and even that started getting line errors on the fourth day. 


Packet audio does need reasonable bandwidth, after all. To support 
several working group teleconferences may require more than a single 
Ti line from the IETF site to the Internet connection point. Beyond 
that point, the next hurdle is wide-area network support for real-time 
traffic. 


To scale up for widespread use of packet audio and video in multiple 
simultaneous public meetings, private teleconferences and other 
applications will require additional research and infrastructure engin- 
eering in several areas including network resource management, IP 
multicast routing and connection/session management. 


The current work on protocols for packet audio and video transport 
over UDP is considered experimental because UDP transmission is 
only sufficient for small-scale use over fast portions of the Internet. If 
many people tried to send packet audio today, significant network 
congestion would likely result. Since packet audio does not practice 
congestion control, well-behaved TCP traffic would back off and let 
the audio take over which is probably not fair. Even so, when there is 
congestion, the resulting packet loss would impair the audio quality 
as well. 


Research is underway on DARTnet and elsewhere to develop resource 
management (or traffic control) algorithms to solve this problem. 
These algorithms, running in the various levels of packet switches in 
the network, would give priority to real-time traffic such as audio and 
video to achieve low delay and packet loss. At the same time, the 
algorithms would prevent real-time traffic from using more than its 
fair share, as determined by payment or policy. On small links with a 
low degree of multiplexing, new calls may be blocked when there is 
insufficient capacity to avoid degrading interference with established 
calls. The audio/video transport protocols may be used in conjunction 
with other protocols such as ST-II [3] or connectionless resource setup 
protocols to access the resource management functions. 
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The tunnel mechanism allows mrouted to establish a virtual internet, 
for the purpose of multicasting only, that is independent of the physi- 
cal internet, and that may span multiple administrative domains. 
However, this capability is only intended for experimental support of 
Internet multicasting, pending widespread support for multicast 
routing by the regular routers. Mrouted suffers from the well-known 
scaling problems of any distance-vector routing protocol, and does not 
(yet) support hierarchical multicast routing or interoperation with 
other multicast routing protocols such as MOSPF. 


A big part of the effort required to set up this audiocast was in 
constructing the multicast virtual network by hand and testing its 
performance. We need multicast routing in the real networks to 
reduce that effort. 


IP multicast addressing works well for broadcast-type applications 
such as this audiocast where a priori agreements on addressing and 
media encoding can be made. A pre-defined multicast address and 
UDP port number are built in to vat, so to join in you just start 
listening. To expand from a single broadcast to multiple, private tele- 
conferences, connection/session management protocols will be needed 
to request call acceptance, negotiate compatible encodings, dynamic- 
ally allocate IP multicast addresses, etc. Since IP multicast traffic 
may be received by anyone, the control protocols must handle 
authentication and key exchange so that the audio/video data can be 
encrypted. 


Like resource management, connection management is the subject of 
current research. We expect that standards-track protocols integ- 
rating transport, resource management, and connection management 
will be the result of later IETF working group efforts. 


Meanwhile, small-scale experiments with packet audio and video are 
encouraged to learn more about the protocol requirements. You can 
participate. A pre-release of the LBL audio tool vat is available by 
anonymous FTP from ftp.ee.lbl.gov in the file vat.tar.Z. 
Included are a Sun-4 binary suitable for use on any version of 
Sparcstation and a manual entry. The authors of vat say the source 
will be released “soon.” 


In addition, a beta release of both binary and source for the UMass 
audio tool NEVOT was recently made available by anonymous FTP 
from gaia.cs.umass.edu in pub/nevot-0.9.tar.Z. 


You can test vat or NEVOT point-to-point between two hosts with a 
standard SunOS kernel, but to conference with multiple sites you will 
need a kernel with IP multicast support added. IP multicast invokes 
Ethernet multicast to reach hosts on the same subnet; to link multiple 
subnets you can set up tunnels, assuming sufficient bandwidth exists. 


You don’t need kernel sources to add multicast support. Pick up the 
file vmtp-ip/ipmulti-sunos411.tar.Z by anonymous FTP from 
host gregorio.stanford.edu. It contains the IP multicast code to 
be added to a SunOS 4.1.1 kernel. 


Once you build the kernel, you should use adb to permanently patch 
the kernel variable audio_79C30_bsize from the standard value of 
1024 to be 180 decimal to match the audio packet size for minimum 
delay. Otherwise there will be bad breakup when sound from two 
sites gets mixed for playback. 
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If you don’t have a microphone for your Sparcstation, Sun is now 
selling one (part number 370-1414) or you can pick up an inexpensive 
microphone from Radio Shack. Walkman-style headphones are also 
recommended. 
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Building & Managing the INTEROP 91 Fall Shownet 
by Brent Chapman, Great Circle Associates 


INTEROP is a yearly networking conference and trade show that is 
considered the “event of the year” by many companies in the net- 
working business. In 1992, INTEROP moves to a twice-yearly format. 
One of the key features of INTEROP is that all exhibitors at the show 
are connected to the “Shownet” so that multi-vendor interoperability 
is actually demonstrated, rather than simply talked about. The Show- 
net is planned, built, and run by volunteers from the industry. 


Last year’s INTEROP Fall conference, held October 7 through 11, 
1991 in San Jose, drew over 32,000 attendees. The exhibits completely 
filled the San Jose Convention Center (all 3 large exhibit halls, the 
ballroom, and the concourse area in front of the exhibit halls), as well 
as the Diamond Pavilion across the street. When completed, the 
Shownet included over 300 vendors, over 400 subnets, and uncounted 
hundreds of hosts. 


The Shownet was a large, diverse network that included many types 
of physical media. These included unshielded twisted pair wire (UTP), 
shielded twisted pair wire (STP), fiber optic cable, and coax cable, as 
well as Tl and microwave links. When the Shownet was finished, it 
consisted of over 30 miles of UTP wire, over 5 miles of fiber optic 
cable, over 4 miles of STP wire, over 1 mile of coax, and untold thou- 
sands of modular connectors. 


The underlying network consisted primarily of Ethernet, Token Ring, 
and FDDI, but many special “demo groups” ran demonstrations of 
other technologies, including Frame Relay, ISDN, and SMDS. The 
primary network protocols used were IP and OSI, but again, many 
demo groups demonstrated other technologies. OSPF was used for 
routing on the Shownet backbone. 


The network was organized into 30 or so “ribs.” In the main exhibit 
halls, the ballroom, and the Diamond Pavilion, ribs were UTP 
Ethernet and Token Ring runs for the exhibitor booths in one or two 
aisles. At the head of each rib was a pedestal containing the 10Base-T 
concentrators and router for that rib. 


The concourse area consisted of three ThinNet (rather than UTP) 
ribs, each with a router at the end. The ribs were further grouped into 
four “backbones,” one for each of the 3 main Convention Center 
exhibit halls running along the front of the exhibit halls, and one in 
the Diamond Pavilion across the street (the ballroom and concourse 
areas were attached to whichever main exhibit hall backbone hap- 
pened to be closest). The rib routers in each backbone were connected 
via FDDI over fiber optic cable. 


Each Convention Center backbone was connected via another router 
to the central network in the Network Operations Center (NOC), 
which was located in one of the “skybooth” offices that overlook the 
main exhibit floor. The Diamond Pavilion backbone was connected to 
the main network via a T3 link. A microwave link connected the ter- 
minal room in the Fairmont Hotel with the main network. The 
Shownet was connected to the Internet through a T1 link to BARR- 
Net. (See Figure 1). 


The group that designed, built, and managed the Shownet included a 
small handful of paid Interop Company employees, but was primarily 
made up of volunteers trading their time for the invaluable experience 
to be gained in working on such a network. 
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There were 3 main groups of volunteers; the Core Team, the Shownet 
Team, and the volunteer laborers. The Core Team comprised 9 indi- 
viduals who were ultimately responsible for the network and who 
worked year-round (starting shortly after the previous year’s INTER- 
OP) to design and build it. They could be considered the “upper man- 
agement” of the Shownet. 


The Shownet Team consisted of 20 to 30 more people who worked 
primarily during the major activity periods (the cabling party in July, 
the hot stage in August, and the actual show in October; all discussed 
below) and were the “staff” of the Shownet. These could be considered 
the “middle management” of the Shownet. 


Finally, and perhaps most importantly, there were the hundreds of 
volunteers who provided labor during the maximum effort periods 
such as the 8-hour period at the start of the show when the physical 
network was installed; the Shownet would not have been possible 
without these folks. 
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Figure 1: The INTEROP 91 Fall Shownet 


The Core Team started planning the ’91 Shownet shortly after the 
close of the previous INTEROP conference (October 1990). By late 
June, they had developed detailed plans for exactly what the Shownet 
was going to look like this year. The Core Team and the Shownet 
Team, plus a number of volunteers, spent the week of July 4 in the 
San Jose Convention Center (when ‘there was no other conference or 
exhibition using the facility) laying out the physical network. The 
various wires were measured, cut, terminated, tested, labeled, and 
bundled into ribs. The ribs were rolled onto cable spools, to be stored 
until reassembly just before the show opened in October. 
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Vendors providing equipment for use in building the Shownet were 
required to deliver the equipment by mid-August, and in late August, 
the Core Team and Shownet Team gathered again, along with vendor 
technical representatives, for a “hot stage” event at the Interop 
warehouse. At the hot stage, all network equipment was assembled 
into the pedestals, configured, and tested. The backbone connections 
were configured and tested as well. The purpose of the hot stage was 
to discover and work out the inevitable small compatibility problems 
in multi-vendor installations. 


In October, the weekend before the show, the Core Team, Shownet 
Team, and the volunteers gathered again to install and test the 
network. On Friday night, the Diamond Pavilion was set up, and 
served as something of a test case for the procedures that were going 
to be used to set up the Convention Center on Saturday night. 


Setting up in the Convention Center was tricky, because the prior 
show (the Seybold Desktop Publishing conference) didn’t release the 
show floor to Interop Company until midnight Saturday, and the 
network cabling that was going up to the ceiling had to be completely 
done by 8am Sunday, when the exhibitors would start arriving to 
assemble their booths. 


Eight hours is not a lot of time to wire a network that size, and it 
would have been impossible if not for the careful planning and the 
several days spent in the Convention Center in July, pre-constructing 
all the overhead cables. 


The Core Team and the Shownet Team spent Sunday through Tues- 
day configuring, testing, and debugging the network. The exhibition 
floor opened to conference attendees on Wednesday at noon; by that 
time, everything was basically working. The two teams spent Wednes- 
day through Friday, while the exhibition floor was open, trouble- 
shooting minor problems that cropped up. After the show closed, 
pretty much the reverse process took place to disassemble everything. 


There are a number of lessons to be learned from working on some- 
thing like the Interop Shownet. First, detailed advance planning pays 
huge dividends. In particular, if not for the detailed advance planning 
that went into this project, it wouldn’t have been possible to meet the 
time constraints (especially that the physical network had to be put in 
place in only 8 hours). 


Second, simplicity is important and valuable. For example, as much 
as possible was done to make the cable plant as generic as possible, by 
pushing wiring differences all the way to plugs or patch cords at the 
ends of connections, so that any UTP cable could be used for any 
purpose, merely by changing what it was plugged in to. Additionally, 
large and complex tools such as SNMP network management systems 
were avoided, because they weren’t really needed. There wasn’t time 
to establish baselines for SNMP performance monitoring, nor was 
SNMP mapping of the network required (the network had just been 
constructed so the Shownet Team and the Core Team knew exactly 
what it looked like). The Shownet was managed with ping, telnet, 
traceroute, and handheld 2-way radios. That’s not appropriate for 
many situations, but it was here, because the situation was highly 
dynamic yet very short-lived. 
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Third, redundancy is also important and valuable. The Shownet 
designers included lots of extra wire pairs in their plans; they didn’t 
really have a use in mind for these pairs at the time, but they realized 
that it would be much easier to bundle extra pairs in when the 
network was being built, and then not use them, than to discover 
after the network was already hung on the ceiling that they needed 
more pairs to cope with some unexpected problem or request. 


As another example of designed redundancy, there were two UTP 
drops to each booth on the main exhibit floor, an “Ethernet” drop and 
a “Token Ring” drop; almost all exhibitors used only the Ethernet 
drop, and the Token Ring drop was in fact intended all along prima- 
rily as a backup Ethernet drop, in case something went wrong with 
the primary. Finally, all FDDI fiber optic backbone connections were 
backed up with UTP Ethernet connections, in case the FDDI fiber 
connections didn’t work for some reason. 


Fourth, pre-planned fallback strategies are important and valuable. 
The INTEROP 91 Fall Shownet had several fallback strategies for 
various services. For instance, if the fiber backbone had failed, a plan 
was in place to fall back to an Ethernet backbone; if OSPF routing 
hadn’t worked, a plan was in place to fall back to RIP; and so forth. 


Working on the INTEROP 91 Fall Shownet was quite a learning 
experience for me. I had an opportunity to work on and learn about a 
wide variety of equipment and technologies, as well as to work with 
and learn from some truly outstanding network planners and man- 
agers. Finally, there’s a great feeling of accomplishment in seeing the 
network come together and knowing that you had something to do 
with its success. If you’re interested in being a Shownet volunteer 
next year, contact Nan Dorio at Interop Company (415-962-2539, 
nan@interop.com). 
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Status of SNMP Evolution 
by James R. Davin, MIT 


The Simple Network Management Protocol (SNMP) network manage- 
ment framework is the collection of conventions on which depend the 
stability, interoperability, and effectiveness of network management 
mechanisms in the Internet. The framework comprises the specific- 
ation for the structure of management information (RFC 1155), the 
definition of a common core management information base (RFC 
1213), and the specification of the SNMP protocol itself (RFC 1157). 
The Internet Activities Board (IAB) conferred Standard status upon 
these specifications in May 1990, March 1991, and May 1990, respect- 
ively. 


This standard network management framework has been and con- 
tinues to be the foundation for a stable, effective network manage- 
ment system in the Internet. Network operators and users daily 
depend upon the robustness and ubiquity of these deployed mecha- 
nisms. 


The easy extensibility of the framework has been the foundation for 
enormous growth in the manageability of the Internet. Based on this 
framework, standardized extensions to the SNMP Management 
Information Base (MIB) have been deployed to manage a variety of 
network media and devices. Additional standardized extensions to the 
SNMP MIB (for both new media and new device types) are currently 
under development within the Internet Engineering Task Force 
(IETF). The framework has also supported deployment of many 
private and experimental extensions to the SNMP MIB by which 
proprietary or advanced functions of the Internet are managed. 


Although applications of SNMP technology are increasingly various, 
the most important function of the SNMP framework in the Internet 
is to support the monitoring and control of network infrastructure. 
The design of SNMP is informed by this purpose. Deployment of tech- 
nology based on the SNMP framework has accrued to network man- 
agers and users tangible benefits that derive directly from key 
architectural principles: 


e The SNMP framework minimizes the overall cost of a manageable 
network by minimizing the cost and complexity of those manage- 
ment system components that are most numerous. 


e The SNMP framework fosters ubiquity of deployment by admit- 
ting the widest possible range of implementation strategies. 


e The SNMP framework fosters operational robustness by realizing 
management system function as closely as possible to centers of 
responsible authority. 


The SNMP framework fosters operational robustness by locating 
control of resources consumed by the management activity (e.g., 
bandwidth, processing) as closely as possible to centers of respons- 
ible authority. 


All human endeavors almost certainly leave room for improvement. 
Accordingly, informal discussion of perceived deficiencies in the net- 
work management framework has arisen from time to time within the 
IETF community. A special session of the SNMP Directorate at the 
July 1991 Atlanta meeting of the IETF provided an open forum for 
such discussion, although the views articulated at that session cannot 
be said to represent a community consensus or even consistently 
informed opinion. 


Evolution 


Written contributions 


Working Group 
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A record of that session is available online at IETF repositories as 
ietf/snmpdir-minutes-91jul.txt. (See page 40 for information 
on how to obtain IETF documents.) 


There is little community consensus on what the actual deficiencies of 
the SNMP framework may be; there is similarly little consensus that 
any particular change to the framework warrants the attendant 
operational or arfhitectural impact. At the same time, organization of 
private efforts towards SNMP evolution have begun among prominent 
providers of SNMP technology. 


The most desirable process for evolution of the SNMP framework 
would be one that combines a prudent regard for the technical and 
operational aspects of the problem with the fairness and openness 
required by IETF procedures. Such a process would: 


e Provide for community consideration of specific evolutionary 
directions without biasing the process towards unnecessary or 
inappropriate change, and; 


e Provide for a consensus on all aspects of an evolutionary path that 
is not dominated by the interests of any particular group. 


To begin the process of SNMP evolution, members of the community 
are hereby invited to submit written contributions that address per- 
ceived deficiencies in the SNMP framework. These contributions must 
be complete and detailed technical specifications that refine, replace, 
or enlarge upon the current SNMP framework. Each contribution 
must be such that interoperable implementations could be 
constructed from it. MIB extensions should not be submitted as 
SNMP evolution contributions since they are dealt with as non- 
evolutionary matters in the normal course of events. Contributions to 
the SNMP evolution discussion should be sent to internet- 
drafts@nri.reston.va.us. All contributions must satisfy the same 
formatting and copyright conditions applied to all Internet Drafts. 


When, in the estimation of the NM Area Director and the IESG as a 
whole, contributions of a sufficient number and quality have been 
submitted, and when all such contributions have been publicly avail- 
able for an appropriate deliberative period, a working group will be 
chartered to consider the submissions. The intent of this two-phase 
process is to assure that any working group effort will start from the 
broadest possible range of submissions and that the community will 
have the opportunity for thoughtful evaluation of all submissions 
before active working group discussion begins. 


By its charter, the working group established to consider proposals for 
evolution of the SNMP framework will have the option of (a) rejecting 
any or all contributions as the basis for positive evolution, (b) accept- 
ing any or all contributions as candidates for standardization, or (c) 
modifying or combining any or all contributions to produce consensus 
proposals for standardization. 


The product of the working group will be a single recommendation to 
the IESG identifying those submitted specifications (or modifications 
thereof), if any, whose standardization as part of the SNMP frame- 
work is agreed to be warranted and desirable. The working group will 
not be chartered to produce tutorial, explanatory, advisory, or inform- 
ational documents of any kind. The working group will be disbanded 
when its consideration of all submitted proposals is complete and its 
single recommendation is made. 


[Ed. Mr. Davin is the Area Director for Network Management in the 
IETF ] 
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SLIP Interoperability 
by Richard Coop, University of Hull 


SLIP provides an easy and inexpensive method of connecting TCP/IP 
hosts with serial lines. It can be utilised to incorporate isolated hosts 
devoid of LAN technology into a network, provide dialup connectivity 
where traffic load does not justify use of a leased line and can provide 
local redundancy in the event of network failure. 


Based upon research performed by the author for the UK Internet 
Consortium, this article discusses several commercial and publicly 
available implementations of SLIP and dialup SLIP for PCs and 
streams and non-streams based SunOS architectures. It highlights 
implementation and interoperability issues, as well as the importance 
of Van Jacobson’s header compression to improve interactive response 
at low link speeds. 


SLIP, the Serial Line Internet Protocol is a simple data link layer 
asynchronous framing protocol for transmission of IP datagrams over 
point-to-point serial and dialup links. As a de facto standard and mem- 
ber of the TCP/IP suite of networking protocols, it resides under the 
IP layer, and being point-to-point requires no network address to 
physical address resolution and hence has no equivalence of the 
Ethernet ARP layer. 


It was conceived in the early 1980s and was first implemented in 1984 
by Rick Adams for 4.2 Berkeley UNIX and Sun workstations [15]. It 
was quickly seen as an easy, inexpensive and reliable method of 
connecting TCP/IP hosts and routers with serial lines. Various com- 
mercial and publicly available implementations were subsequently 
developed for Ultrix, SunOS and most other BSD derived systems as 
well as for IBM compatible PCs. 


Almost all UNIX workstations and PCs incorporate ubiquitous serial 
hardware, mainly RS-232. With the advent of low cost X terminals 
and workstations capable of supporting increasingly faster serial 
lines, coupled with the simplicity of the software itself, SLIP can pro- 
vide a simple and inexpensive communication medium. 


Traditionally telecommuters utilised modems and communications 
software to connect to remote computer systems. Data, however, had 
to be taken out of packetised form and converted into character form 
before being transmitted over the dialup telecommunication link. By 
utilising SLIP, and hence TCPAP packetised data, multiple sessions 
can be established to multiple hosts. File transfers are also easier as 
almost all TCP/IP hosts implement an FTP server. 


SLIP can be used to incorporate isolated hosts into a network where 
they are located in buildings devoid of LAN technology or the cost of 
utilising such technology is not justified by traffic load. It can be used 
to interconnect TCP/IP LANs, where gateway machines lack a second- 
ary Ethernet card or the cost of the additional hardware is not justi- 
fied by the internetwork traffic. In dialup WAN applications, SLIP 
can provide temporary connectivity when the cost of a permanent 
dedicated leased line is unjustified. 


The main advantage of SLIP is also its main deficiency; simplicity. 
The basic SLIP protocol makes no provision for dynamic address 
assignment, error detection or correction, header compression and 
only supports the IP protocol family (though others can be supported 
by encapsulation within IP at the expense of performance). Essenti- 
ally SLIP provides no way to communicate or negotiate information 
that may differ between each end of the link. 


SunOS 
interoperability tests 
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In order for SLIP to operate, each end of the link must know the 
other’s IP address. Since a SLIP implementation cannot automatically 
inform the remotely connected implementation of its IP address, 
static IP addresses must be assigned to both ends. This normally 
involves two humans verbally agreeing on the addressing scheme to 
be used. As will be detailed later, header compression can optionally 
be utilised in some versions of SLIP. Although its specification out- 
lines a methodology for communicating to the other host whether or 
not it is implementing compressed SLIP, this negotiation procedure 
must normally be performed manually. 


Though SLIP is publicly available via anonymous FTP for several 
UNIX derived systems, due to hardware restrictions the author was 
limited to implementing SLIP for the SunOS subset. Those investi- 
gated and their availability are summarised in Table 3. 


Although installation and use of such packages might appear straight 
forward this was found to be an ill judgement. Some implementations 
contained erroneous or missing code and coupled with the need to 
manually configure static SLIP parameters such as IP addresses, 
installation demanded a reasonable degree of competence on the part 
of the administrator. 


Each SunOS package was installed on the relevant hardware and 
tested with both itself and each of the others in turn, utilising a “null 
modem” RS-232 cable between the two workstation ports running at 
9600bps. The results of this simple interoperability test are illu- 
strated in Figure 1, where the clear boxes indicate successful inter- 
operability. 

TO 


SLIP'3:x SLIP 4.0.x | SLIP 4.0.x | SLIP 4.1.x | SLIP 4.1.x 
compressed 


SunOS 3.5 | SunOS 4.0.3 | SunOS 4.0.3 | SunOS 4.0.3 | SunOS 4.1.1 


SLIP 3.x 
SunOS 3.5 


SLIP 4.0.x 
SunOS 4.0.3 


SLIP 4.0.x 
compressed 


FROM 


SLIP 4.1.x 


SLIP 4.1.x 
SunOS 4.1.1 


Figure 1: Interoperability of SunOS SLIP implementations 
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The shaded boxes indicate unsuccessful interoperability and in these 
cases the remote host could be pinged and the connection established 
successfully but no getty enabled. Although the “connected” message 
appeared, the connection hung until the FTP or telnet application 
timed out. 


The SLIP4.0 implementation is really intended to be used as a login 
shell for an incoming dialup connection. The sliplogin program that 
comes with the package can, however, be invoked as root to establish 
the network parameters explicitly and thus establish a local hard- 
wired link. It was found that the program incorporated an inactivity 
timer and it was necessary to initially ping the remote host once the 
link had been established, else the route timed out and was deleted. 


As SLIP4.0 with header compression is based on SLIP4.0 it exhibits 
the same problem as well as failing to interoperate with any other 
package than itself. This latter defect seems to be caused by the 
implementation failing to implement the full RFC as detailed later. 


Ping round trip times were in the order of 210ms. FTP throughput, 
measured by averaging the throughput of the ls command in various 
directories, was in the order of 0.3Kbytes/s with the exception of com- 
pressed SLIP where it increased almost threefold to 0.83Kbytes/s. 


There are several versions of SLIP available for IBM compatible PCs. 
The two utilised were the latest version of Phil Karn’s KA9Q@ package 
and FTP Software’s PC/TCP generic kernel implementation utilising 
a packet driver, the former publicly available via anonymous FTP for 
academic and packet radio users, the latter being a commercial imple- 
mentation [19]. Both were reasonably straight forward to install and 
their availability is detailed in Table 3. 


Both packages were tested for interoperability with a hardwired 
9600bps RS-232 link to all the SunOS SLIP implementations previ- 
ously outlined. In order to communicate successfully, however, it was 
found necessary to manually reconfigure both KA9Q and PC/TCP to 
reduce the MSS and window values to 966 bytes (maintaining the 
Maximum Transmission Unit (MTU) value at 1006 bytes) to corre- 
spond with those of the SunOS SLIP implementation. 


Both KA9Q and PC/TCP were able to communicate with all SunOS 
SLIP implementations with the exceptions of SLIP4.0 with header 
compression and SLIP4.1 (Under SunOS 4.1.1), the former being due 
to SLIP4.0c’s inability to send out uncompressed packets. The FTP 
throughput results for PC to SunOS and vice versa are given in tables 
1 and 2 respectively. 


SLIP 3.x SLIP 4.0.x SLIP 4.0.x SLIP 4.1.x SLIP 4.1.x 
compressed 
SunOS 3.5 | SunOS 4.0.3 SunOS 4.0.3 | SunOS 4.0.3 | SunOS 4.1.1 


FROM 


Table 1: PC to SunOS FTP throughput (Kbytes/s) 


Compressed SLIP 


Availability 
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FROM 


SLIP 3.x SLIP 4.0.x | SLIP 4.0.x | SLIP 4.1.x | SLIP 4.1.x 
compressed 
SunOS 3.5 | SunOS 4.0.3 | SunOS 4.0.3 | SunOS 4.0.3 | SunOS 4.1.1 


Table 2: SunOS to PC FTP throughput (Kbytes/s) 


It can be seen than PC/TCP appears to be slower than KA9Q. This 
can be attributed to the PC/TCP implementation utilising a packet 
driver, whereas KA9Q communicated with the native serial hardware 
directly. FTP Software, Inc. supplies a version of PC/TCP for SLIP 
that works directly with the hardware and if utilised, performance 
could be considerably higher. 


Header compressed SLIP was conceived by Van Jacobson several 
years ago, motivated primarily by the need to improve typical key- 
board echo response during interactive sessions such as telnet. 
Response has been shown to be perceived as “poor” when low level 
keyboard echo takes longer than 200ms [7]. By reducing the size of 
the TCP and IP header overhead, the 200ms echo to a character typed 
can be received over a slower link and the resultant smaller data- 
grams cause less interference with bulk data traffic. 


For most TCP conversations datagram fields for successive datagrams 
often remain constant or change by a fixed amount and thus redun- 
dant header information can be cached by only transmitting the fields 
which changed from one datagram to the next. 


As far as the author is aware, compressed SLIP is currently available 
for SunOS 4.0.x as detailed in Table 3 and although available for 
SunOS 3.x, it is still in the experimental stage of being ported back to 
a non-streams environment. 


Though the compressed SLIP for SunOS 4.0.x has options to enable 
and disable header compression, auto enable and ICMP reject, none of 
these options seemed to be implemented. The compression code was 
edited and code added to report the progress of incoming and outgoing 
packets and whether or not they were compressed. Investigation 
revealed that although the implementation is prepared to accept nor- 
mal datagrams it only transmits compressed ones. This is the reason 
for the interoperability problems experienced in the previous hard- 
wired cases. The two computers exchange normal TCP datagrams to 
negotiate MSS values and establish the session, but the compressed 
implementation then only transmits compressed packets causing the 
other computer to drop these and eventually time out. 


To investigate the effects of header compression, a Sparc Station 1 
running SunOS 4.0.3 was configured with both basic SLIP4.0 and 
SLIP4.0 with header compression in succession. A SLIP link was 
established between its two serial ports by the use of a “null modem” 
RS-232 cable and for each configuration, over a range of available 
data rates, the average telnet echo response and FTP throughput were 
recorded. As expected, at any given data rate, the ping round trip 
times were found to be approximately equal for both implementations 
(UDP ICMP packets are not compressible). 


continued on next page 
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The results of the effect of header compression on telnet echo response 
and FTP throughput are illustrated by Graphs 1 and 2 respectively. 


o normal 


® compressed 


Echo Response (s) 
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Graph 1: Effect of compression on telnet echo response 
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Graph 2: Effect of compression on FTP throughput 


From Graph 1, it can be seen that header compression has a marked 
effect upon interactive response. Without compression, telnet response 
starts off poor but increases rapidly to a knee point of around 1200bps 
but then improves slowly, the 200ms acceptance threshold being 
achieved at a poor 14Kbps. With compression enabled, telnet echo 
response starts off almost 3 times faster and the 200ms threshold is 
reached at an acceptable 2400bps. Above this point response improves 
rapidly and at 9600bps response can easily be compared to that of a 
moderately loaded Ethernet. 


From Graph 2, it can be seen that without compression, throughput is 
linearly related to line speed but then falls off around 4800bps as the 
streams implementation fails to cope with the large datagrams at 
such high speeds. With the smaller compressed datagrams, however, 
the streams implementation is easily capable of transmission of 19.2 
Kbps, reaching a surprisingly fast throughput of around 2.7Kbytes/s. 


As a final test, the effect of additionally increasing the size of the 
Maximum Transmission Unit (MTU) was investigated for compressed 
SLIP. To analyse the effect this would have on telnet response and 
FTP throughput, the MTU was increased from 296 to 600 bytes. The 
resultant effect upon telnet echo response is illustrated by Graph 3. 


From Graph 3 it can be seen that by increasing the MTU response has 
become more uniform, the critical point occurring around 2400bps. 
Below this, telnet response is further improved by increasing the MTU 
size while FTP throughput remains approximately constant. Above 
this, increased MTU size actually reduced echo response and FTP 
throughput quite significantly. 
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Graph 3:Effect of increased MTU on echo response (compressed SLIP) 


Dialup SLIP allows TCP/IP to be run over intermittently connected 
telephone lines and one of the initial limiting factors in its develop- 
ment was that dialup modems in the early 1980s as well as being 
expensive were too slow to provide acceptable performance. As low 
cost, high performance 9600 bps modems become available Dialup IP 
became a reality. The author investigated two publicly available 
packages; DialupIP and tip with SLIP support. 


DialupIP is a publicly available implementation that provides an on- 
demand dialup IP service based on a modified SLIP driver distributed 
with 4.3BSD [11]. It provides full IP support over dialup phone lines 
and runs on Ultrix, SunOS 3.5 and 4.3BSD UNIX platforms and has 
successfully been used to connect to both dialupIP and Toronto’s 
SLIP4.0 package as well as Phil Karn’s KA9Q package for PCs [6]. 
When a datagram is required to be sent, the line is brought up if not 
up already. Access can be restricted to source host or network, destin- 
ation host or network, time of day, or protocol. On receiving an in- 
coming dialup connection, security is provided by ensuring the user 
logs into the system. Only when this has been achieved will control be 
passed to the dialupIP login shell that is used to set up the line 
discipline. 


One disadvantage of such an on-demand dialup/P service is that the 
time taken to dial the modem and set up the line can be very long; 
longer than the timeout values of applications such as FTP or telnet. 
Dave Smith at whoops.ftp.com in the US has found that dialupIP 
fails to deliver DCD dropped signals correctly to the process, and that 
getting utilities to use the Domain Name System (DNS) rather than 
Sun’s Yellow Pages is exceptionally difficult without source code. 
Modem support is also poor; it is only configured for three automatic 
call units. Work is currently being performed to port dialupIP to 
streams-based SunOS systems [6]. 


Tip with SLIP is a modified version of the tip utility running under 
SunOS 4.0.x that allows the SLIP4.0 and header compressed SLIP4.0 
code to be brought up after tip has successfully established the con- 
nection. It is available by anonymous FTP as detailed in table 3 and 
provides on-command dialup service that is essentially the partner of 
SLIP4.0 and header compressed SLIP4.0. Tip with SLIP is used to 
establish an outgoing dialup IP connection and SLIP4.0 provides the 
login shell for incoming dialup IP connections. 


Once again, installation was found to be harder than anticipated. The 
login.c login script processor code required debugging and the 
Makefile required editing to configure the auto call unit in use and to 
set the path for installation of man pages. 
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Once installed, it was used to establish an internal 1200bps dialup 
SLIP connection to another machine running SLIP4.0 using a Mira- 
com HST modem to dial out and a simple Racal MPS1222 modem to 
answer. However, it was found that tip with SLIP locked up the ter- 
minal it was invoked on and a route had to be established from 
another machine connected by Ethernet to the locked workstation in 
order to communicate across the dialup link. Having established 
interoperability, the two machines were then rebooted with com- 
pressed SLIP4.0. Interoperability was maintained and response was 
significantly improved as expected. 


A 1200bps national dialup link was successfully established between 
Edinburgh and Hull with the cooperation of Keith Mitchell of Spider 
Systems, Edinburgh. In Edinburgh a Telebit Netblazer was utilised to 
invoke the dialup SLIP link and in Hull SLIP4.0 used to provide the 
login shell for the incoming dialup connection. It was discovered that 
although the receiving getty was asserting parity correctly, the login 
program did not. It was found necessary to include a “p8” in the 
gettytab entry at Hull to force 8 bit data, no parity on the line. This 
seemed to resolve the problem and the link operated successfully. 


By reconfiguring both ends of the link with compressed SLIP, res- 
ponse was noticeably improved. However, due to possible deficiencies 
with the Netblazer compression implementation, it was necessary to 
set its Van Jacobson compression to “on” as setting it to “auto enable” 
caused it to crash. 


Both KA9Q and PC/TCP utilise a command to dial a modem and 
establish a dialup link. It was discovered that although PC/TCP could 
establish the link, parity was not being asserted correctly and charac- 
ters could not be interpreted; in the author’s opinion the problem lies 
not with PC/TCP but with the modem utilised. KA9Q was unable 


even to set up a connection. 
SOURCE(S) SYSTEM 
4.2 BSD 


uunet.uu.net: networking/sl.shar.Z 
SLIP'3:x i 
neal.ai.toronto.edu: pub/slipware.tar.Z SunOS 3.x 


SLIP 4.0 uunet.uu.net: networking/slip/slip-4.0.tar.Z SunOS 4.0.x 
` neat.ai.toronto.edu: pub/slip-4.0.tar.Z SunOS 4.1 


SLIP 4.0 f Wionedid Z SunOS 4.0.x 
compressed tp.ee.lbi.gov: cslipbeta.tar. SunOS 4.1 
SLIP 4.1 beta dmssyd.syd.dms.csiro.au: pub/slip-4.1.shar SunOS 4.0.x 

SunOS 4.1.x 
Tip with SLIP neat.ai.toronto.edu: pub/slipware.tar.Z SunOS 4.0.x 
SunOS 4.1 
Ultrix 
DialupIP uunet.uu.net: networking/dialup2.0.tar.Z 4.3 BSD 
SunOS 3.5 


KA9Q thumper.bellcore.com: ka9q/net.exe 


PC/TCP FTP Software, Inc. 


Table 3: Sources of SLIP implementations examined 
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The Internet community realised several years ago that a proposed 
new standard protocol for serial connections was required. It would 
address all the deficiencies of SLIP and be flexible enough to address 
future needs. The result is PPP, the Point-to-Point Protocol [13, 17]. 


However, PPP has taken time to reach its present state of complexity 
and can prove too complex for most requirements. SLIP, on the other 
hand, has been around for a long time, is easier to implement and is 
easier to understand. As a consequence, SLIP became the de facto 
standard for TCP/IP dialup networking. 


As TCP/IP implementations become available for increasingly cheaper 
computers, the use of voice grade dialup network connectivity will 
further increase. However, as networking becomes more and more 
complex and the need to transmit protocols other than TCP/IP across 
asynchronous and synchronous dialup links increases, PPP will 
replace SLIP as the standard for point-to-point networking. 


Unfortunately PPP was not intended to phase out SLIP gradually, 
and converting from SLIP to PPP can be difficult. It seems contented 
users of SLIP are presently happy to continue using it until PPP has 
become established. 


It has been shown that publicly available implementations of SLIP 
exist that can be utilised to provide simple and inexpensive hardwired 
and dialup IP connectivity, and that header compression can signifi- 
cantly improve the performance of the basic protocol. 


Although the concept of SLIP is fairly simple, it should be stressed 
that implementation was found to be more difficult than first antici- 
pated. Coding was found to be erroneous and much of the docu- 
mentation assumed a fairly high degree of UNIX competence on the 
part of the administrator. In addition, network administrators must 
be prepared to manually negotiate and agree on parameters such as 
local and remote IP addresses and the link data rate. 


As TCP/IP implementations become available for increasingly cheaper 
computers, the use of voice grade dialup network connectivity will 
further increase. However, as networking becomes more and more 
complex and the need to transmit protocols other than TCP/IP across 
asynchronous and synchronous dialup links increases, the Point to 
Point Protocol will replace SLIP as the standard for point-to-point 
networking. 
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Introduction 


Bigots 


The Interoperability Report 


Opinion: OSI Is (Still) a Good Idea 
by Richard desJardins, The GOSIP Institute™ 


OSI is the de jure international standardization component of world- 
wide computer networking. It is a joint program of ISO and CCITT, as 
well as the major world governments. OSI is used in public systems 
such as the world telecommunication networks, the public message 
handling system, and public directory services, as well as the US and 
UK Government OSI Profiles (GOSIPs) and the European Procure- 
ment Handbook for Open Systems (EPHOS). 


The Internet is the worldwide public domain internetwork. The Inter- 
net runs not just TCP/IP, but is multiprotocol and inclusive. TCP/IP is 
accepted worldwide as the public domain (de facto) standard for com- 
puter network interoperability. The Internet has done a lot of things 
right. 


OSI has done a lot of things right too. Everyone uses the Reference 
Model to compare protocol architectures. Many architectures use the 
OSI Service Definitions, or at least the concept of service definitions. 
Neither of these two things were ever successfully developed in 
TCP/IP because the Internet was out implementing and deploying 
protocols, and the architecture and service definitions were just, well, 
whatever they were. (Who cared? The entire community was a few 
researchers who worked together and learned as they went.) Now the 
Internet is much more formal, and has its own standardization 
procedures, which are becoming more ISO-like (no surprise). 


The Internet recognizes OSI standards today (e.g., IEEE 802 LANs, 
CLNP, Object Identifiers, X.500, all of which are International Stand- 
ards), along with proprietary standards such as Novell IPX and 
AppleTalk, along with consortia standards such as The X Window 
System and Unix International, along with its own RFC standards. 
The Internet protocol suite will continue to recognize OSI standards. 


The Internet Society has become the public domain network standard- 
ization body, and its RFCs are recognized as public domain standards 
in their own right. This acceptance has accelerated the Internet trend 
toward multiprotocol accommodation and inclusivity. The Internet 
Activities Board (IAB) now has the same responsibilities and the same 
due process requirements in their approval of standards as the ISO 
Council or the CCITT Plenary. 


This emergence of TCP/IP as a peer to ISO and CCITT is all to the 
good, just like the convergence of cultures and races in the world at 
large: the only people who object to it are the bigots, whether they are 
spelled “OSI Bigots” or “IP Bigots.” (As someone said at the recent 
ROAD meeting, “Unanimity might be achieved—if we shoot a few 
people.”) 


I say, “let’s make a deal.” If we (OSI) admit that some of our stuff 
(Session Layer, for one, which Marshall Rose calls “The Sewer of 
OSI”) is not so good, will you (IP) admit that some of our stuff is really 
the best solution and should be used in the Internet, even if it’s 
spelled ‘OSI’? Then let’s continue to get the people of good will from 
both communities to work together to find the best solutions, whether 
they are two-letter words or three-letter words, and let’s just line up 
the bigots against a wall and shoot them. 


(desJardins’ First Law of Protocol Naming: Ya can call it “IP” or ya 
can call it “TCP/IP,” but ya doesn’t has ta call it “Internet.”) 


continued on next page 
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7 Fearless Predictions 


CLNP 


Routing 


CONS 


Implementors 


OSI Is (Still) a Good Idea (continued) 
Seven is not a magic number, but it works for me: 


1. The IP Bigots are spinning like dervishes to make IP solve all the 
future address growth and routing table growth problems, simply 
because they hate to use anything spelled “OSI.” But the true fact is, 
CLNP can readily solve both those problems, because CLNP is just IP 
with a big address space. With CLNP, systems can have two or three 
addresses, e.g., an IP address (if they get one soon, before they run 
out), a network address, and a GOSIP organization “address” (which 
is really an organization global name plus an internal address, but is 
not a global address). The inter-domain routers (after all, there aren’t 
really so many of these) can be smart about how to handle the differ- 
ent addresses to cut down on routing table size, implement policy 
routing and type of service routing, etc. 


Fearless Prediction #1: CLNP will be accepted as “IP—2.” (We may 
have to shoot some people, but, hey, the Indians got in the way of 
Manifest Destiny.) 


2. As long as we’re talking CLNP, let’s face it, OSI routing protocols— 
i.e., ES—IS, IS-IS, and IDRP—are as good as or better than IP routing 
protocols, because OSI was able to apply all the lessons learned from 
years of making IP routing protocols work. So the IP Bigots have to 
listen to this: CLNP, ES-IS, IS-IS, and IDRP are really good stuff! 


Fearless Prediction #2: IDRP will be used as the single inter-domain 
routing protocol for both IP and CLNP. 


3. Roll over, Beethoven, because Connection Oriented Network Ser- 
vice (CONS) is not dead yet. (CONS is not really spelled “X.25,” folks.) 


Fearless Prediction #3: The network paradigm is going to shift again 
by the end of the decade: Transport service will use CONS when it 
makes economic sense for point-to-point and isochronous traffic, and 
CLNS when it makes sense for multi-point and bursty traffic. (And 
speaking of Transport, there will be a “TP5” some day soon, with 
screaming performance—would you believe 1Gbps?—based on rate 
control and selective retransmission on top of CONS environments.) 


4, A word about “implementors”: A lot of the trouble with OSI is with 
the implementations, not with the standards: In too many cases, 
they’re expensive, not terribly robust, and poorly integrated with the 
rest of the product line. For example, why don’t we see “skinny” upper 
layer stacks, which OSI readily allows? Because in many cases the 
implementors built the upper layers as three protocol machines, each 
with full functionality, no matter whether applications needed it or 
not! OSI wasn’t designed like that, it was implemented like that. And 
the biggest implementation of them all is ISODE, which is a perform- 
ance and memory hog. (This is appropriate for its mission, which is a 
development environment, not intended as a production system, but 
some of the “implementors” from the vendors just took it and product- 
ized it.) Not the way to do it, guys! Talk to Jim Quigley (chair of the 
NIST OIW Upper Layers SIG) about the OSI Skinny Stack, which 
arose from work in ANSI and EWOS to run the X Window System 
over OSI [1]. As implemented at the University of London Computing 
Centre, the Skinny Stack can run many of the current and future OSI 
applications with 2K lines of code (compared with the 30K+ lines of 
code in many if not most OSI upper layer implementations). TCP/IP 
code comes free with UNIX, whereas you have to pay for OSI. Which 
one would you buy? 


Cheap standards 


The Future 


The test 


The Interoperability Report 


Fearless Prediction #4: OSI will come free with UNIX by the end of 
the decade, and will finally be accepted when Distributed Transaction 
Processing and Remote Procedure Calls run like banshees over the 
OSI Skinny Stack. 


(Let’s put out an RFC for the Skinny Stack, and fast-track it through 
ISO. It takes only months, not years. That should make Marshall 
Rose happy, and it is certainly a needed addition to ISODE! Let’s 
make the skinny profile a NIST OIW, ISO ISP, and GOSIP standard. 
Aside to the OSI Regional Workshops: Why didn’t we do this three 
years ago?) 


5. Let’s get the standards published cheap, or free. Standards should 
be the price of a technical book, or cheaper, and it should be legal to 
make copies of them and FTP or FTAM them across a network. Accor- 
ding to some copyright experts, ISO and CCITT don’t “own” their 
standards, they just claim they do. Their standards are developed in 
the public domain, then just before being published are slapped with a 
copyright notice so that you have to pay their prices. (By the way, 
FTPing standards across the Internet is not “free,” you just don’t have 
to pay for it. It costs about the same as printing and mailing a paper 
copy.) So ISO, CCITT, and Internet standards should all be freely 
available at low or no cost. The way to make this happen is happening 
now: The Internet Society is effectively challenging the established 
standards bodies to open up their process. I think it’s going to work. 


Fearless Prediction #5: By the end of the decade, the Internet, ISO, 
and CCITT are going to be working together to publish the standards 
for the Worldwide Internet at low or no cost. (As Carl Malamud might 
say, still smarting from his aborted experiment to make the CCITT 
Recommendations available on the Internet via Anonymous FTP, 
“Right, and monkeys are going to fly out of my butt!”) 


6. Fearless Prediction #6: The future of network computing is: Appli- 
cations will run on top of APIs, which will plug into XTI/TLIs, which 
will run over various Transports, which will run over CONS and 
CLNS, which will all come free in your UNIX boxes. (We're talking 
about a few hundred lines of code here and there, come on, guys, don’t 
make people pay extra money for this!) X/Open will continue to occupy 
a key role here. By the end of the decade, UNIX software will be 
distributed on 10 CD ROMs, of which half will be for The X Window 
System and MOTIF. (Just kidding on that last one, I think.) 


7. The test of a good standard will become (as it should be): Does it 
provide the needed functionality? Is it cheap to implement? Does it 
work as a good citizen in the Internet? Not: Is it spelled “IP”? Or: Is it 
spelled “OSI”? And speaking of testing (was I?): 


Fearless Prediction #7: “One world testing” (i.e., test a product just 
once to certify it for the worldwide ISO/CCITT/Internet market) will 
be done with a modestly sized suite of worldwide standard tests for 
each protocol standard. Maybe COS, SPAG, and INTAP can get 
together and figure out how to do this at a reasonable cost. (Please?) 


[1] Peter Furniss, “The OSI Skinny Stack,” University of London 
Computing Centre, March 1992. 
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has an M.S. in computer science from the University of Maryland as well as degrees 
in mathematics and physics from Catholic University. 
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Letters to the Editor 
Ole: 


In looking at the nicely humorous article by Jon Crowcroft in the May 
1992 (Vol 6, No 5) issue of ConneXions, I found that the chart seemed 
to me to be a bit at odds with my subjective memory of the variations 
in the production of RFCs. I certainly did not recall that the pro- 
duction rate was so high in the early 70’s, and i was sure the rate was 
quite a bit higher than shown in the chart in the last few years. 


I decided to draw a graph based on data from the “rfc-index.txt” 
file provided by the SRI International Network Information Service 
Center (SRI-NISC). This is in close agreement with Jon Crowcroft’s 
chart for about the first 2/3’s of the data, but is substantially different 
in the last 1/3. 


—dJon Postel, The RFC Editor, USC-ISI 


Number of RFCs Produced per Month 


30.0 5 
V 
O 
E 
ua 
B 
D 
Q 
Z 
=: | 
= 
0.0 120.0 240.0 
Month Number (0 = Jan 69 ) 
Ole, 


I concur with Jon Postel’s correxion—on looking at the raw data, my 
awk script must have gone awry. 
—Jon Crowcroft, UCL 


We appreciate the feedback and the corrected histogram. It just goes to 
show what you can do with some statistics and a graph. Perhaps 


someone will send us the equivalent histogram for OSI documents. 
—Ed. 


My opinion article “The 
Trouble with OSI,” in the 
May issue of ConneXions 
triggered quite a few 
reactions. In addition to 
the article on page 33 of 
this month’s issue (and 
promises of more articles 
from other quarters), we 
received some letters (all 
of them from “Bob” for 
some reason :—) 


The Interoperability Report 


Dear Ole, 

Just read your opinion on the trouble with OSI, and I agree. I see 
TCP/IP and OSI merging, with bigots on both sides mellowing out to 
the good of all. For example, I see X.400/X.500 coming in over TCP/IP. 
Now, where does ISDN fit in? And, while you’re up, how about HDTV? 


—Bob Metcalfe, InfoWorld 


Ole, 
I don’t basically disagree, but I would like to see an important point 
made about the failure of OSI: 


The tradition of the Internet is that standardization follows imple- 
mentation. Also the people putting the effort into doing experimental 
implementations of draft standards get a lot of say (including a veto 
on extra features) as the standardization process comes down to the 
wire. 


My recent experience of the IETF standardization process suggests 
that there is a danger from people drifting over to the IETF process 
from the OSI standardization world who do not support this tradition. 
Since I think that tradition is fundamental to the success of the Inter- 
net, I would like to see it emphasized at every possible opportunity. 


—Bob Smart, CSIRO, Australia 


Ole: 

I found much to agree with in your “Opinion: The trouble with OSI” 
op-ed piece in the May ConneXions. OSI did indeed bite off a very 
large mouthful, probably more than we all realized at the time [I was 
the editor of X.200 during the 1980-84 Study Period]. Generally, 
there was always some regional standards group that arrived at every 
meeting with a partially developed protocol which they would push 
very hard. Of course the NIH factor would come into play and there 
would be another regional group with YAP (Yet Another Protocol). 


There was not only the mistrust (net bigotry?) between the ISO camp 
and the Internet people, but also the mistrust and mythological 
differences between the computer and telecom people. Also, there are 
many people who are unaware of how the standardization process 
works. In the United States, under ANSI rules, anyone may partici- 
pate and those with the knowledge should participate. Instead, those 
of us who went to all of those exotic cities, to the envy of cur fellow 
workers, got to do the work. Regarding most of those cities, I can show 
you the path from the hotel to the meeting place and little else as 
there was no time for sightseeing. 


As to standards being under constant revision, in 99% of the cases all 
those revisions must be backward compatible. In CCITT we had to 
assure this since the carriers and administrations had to grandfather 
all existing customers. Sadly enough, neither ISO nor the CCITT have 
ever “gone online” with this work in an effort to expedite the work. 
Standards making is part technology, part marketing, and part diplo- 
macy—not a simple job description. In my 10+ years involved with the 
process, I met very many people for whom I have a great deal of 
respect. The long hours, the travel, and the preparation are demand- 
ing. I keep thinking that one day I may write a book on how many 
marriages have broken due to the enforced separation. I am not 
suggesting that you “Take a standards person to lunch,” but all people 
involved in this area should make themselves aware of the process 
and find out if and where they can contribute. There certainly is no 
shortage of work, just a shortage of workers. 


—Bob Blackshaw, Corporation for Open Systems International 
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Organisation 


Comparison 


Evangelism 


Cabling 


Book Review 


Open System LANs and their global interconnection, by J. Houlds- 
worth, M. Taylor, K. Caves, A. Flatman, and K. Crook, Butterworth 
Heinemann, 1991, ISBN 0-7506-0145-X (Paperback). 


Serendipity. I was in the process of compiling ISODE 7.0 and contem- 
plating installing PP, when I came across this book. I didn’t find it 
particularly useful in getting ISODE up and running, but it was an 
interesting book nevertheless. 


It seems that most books about OSI are meant for reference, and at 
first glance, this looked to be no exception. The book starts off nice 
and easily with a brief introduction to LANs and WANs in the first 
chapter and a basic introduction to the seven layer model (though, 
surprisingly perhaps, very little explanation of the reasoning behind 
the seven layer model). 


The book then goes on to describe the standards in detail starting at 
the physical layer and working up. (Why can’t people be more origi- 
nal?) The chapter on LAN Standards covers Ethernet, Token Ring, 
Slotted Ring, FDDI and MAC bridging, all fairly comprehensively— 
most sections including cabling specification, signaling topology con- 
siderations and management of each particular type of network. The 
coverage of the data link layer, network layer (which includes X.25) 
and transport layers are equally thorough, with chapters devoted to 
each. 


The authors then attempt to briefly compare OSI to some other net- 
working standards, namely TCP/IP, Microsoft’s LAN Manager and 
Novell’s NetWare. After that come chapters on Network and OSI 
Management, and structured building cabling. The book ends with a 
chapter on future directions of OSI, which includes information on B- 
ISDN, ATM and FDDI-II. 


The main problem with this text is the occasional habit of the authors 
of lapsing into evangelising. This is particularly marked when they 
are talking about OSI in relation to other protocols. However, where 
the book avoids this, it is clearly written and comprehensive, with a 
high signal to noise ratio. Where the authors avoid excessive use of 
acronyms (hard in an OSI text), its readable too. Even when you get 
stuck, you’ve got 2 appendices (28 pages) of glossary and referred-to 
standards. 


The comparison chapter is a little out of place—the comparisons are 
only very basic and don’t do justice to the non-OSI protocols, especi- 
ally TCP/IP. The book would probably be better without it, and it 
should have just concentrated on defining OSI. I was pleasantly sur- 
prised to find the chapter on cabling in your building, because you 
don’t usually find useful information like that in this sort of book. 


Will I keep this book on my shelf? Yes, I think so. Will I use it? Again, 
probably. 
—Matthew Farwell, UK IBM PC User Group 
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The NEARnet Trouble Ticket System 


Bolt Beranek and Newman is pleased to announce the availability of 
The NEARnet Trouble Ticket System. The system allows problems 
and their related working notes to be maintained in a coordinated 
fashion, and provides for automatic distribution of ticket information 
via electronic mail. 


The system is built on the INFORMIX Relational Database running 
on a Sun Sparcstation. It uses the Embedded-SQL (in C) package to 
interface to the mail system (currently MMDF). The system includes 
the necessary definitions for the INFORMIX “forms” front-end, which 
is used for ticket data entry and searching. The system also includes 
C code to provide finger-based access to tickets in the database. 


The system grew out of a weekend hack (as most useful things do). It 
has evolved as people have requested new features. As such, it suffers 
from a lack of “clean design” and has a fair amount of NEARnet/ 
MMDF-specific stuff in it. There are several things I would have done 


very differently if Pd known other folks would be looking at the guts of- 


it >). 


In practice, however, this system has been immensely useful to us and 
has helped NEARnet gain a reputation for, among other things :—), 
persistent and thorough problem resolution. I hope that this system, 
while it may not be immediately useful in your environment, will at 
least serve as a model for the kind of thing that can be built around 
an off-the-shelf database package. 


The current release package was prepared by Leo Dopson and John 
Curran. It contains several descriptive documents in the docs direct- 
ory and an easy-to-use installation script that will customize the 
system to your network’s requirements: bin/install_ticket_system. 


In the future, we hope to provide improvements to the system, inclu- 
ding making the package more tailorable, adding Sendmail support, 
and adding more of the features proposed by the IETF User Connect- 
ivity Problems Working Group. To facilitate this process, please feed 
any improvements you make to this package back so we can all 
benefit. 


The system is available via anonymous FTP on nic.near.net in the 
file: 


pub/nearnet-ticket-system-vl.2.tar 


Bug reports, discussion, fixes, improvements, questions should be 
addressed to: 


tt@nic.near.net 
To join this list, mail to: 
tt-request@nic.near.net 
—Dan Long 


Senior Network Analyst 
BBN Systems and Technologies 
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Internet-Drafts 


RFCs 


More information 


Getting Internet-Drafts 


Internet-Drafts documents represent work-in-progress of the Internet 
Engineering Task Force (IETF). It should be noted that Internet- 
Drafts are not standards and systems should never be cited as “in 
compliance with” the drafts. Internet-Drafts are available by anony- 
mous FTP. Login with the username “anonymous” and password 
“guest.” After logging in, type “cd internet-drafts” and “get 
<filename>.” For example: 


“get draft-ietf-osids-simple-stack-00.txt” or 
“get draft-ietf-osids~simple-stack-00.ps” 
Internet-Drafts directories are located at: 

° Kast Coast (US): 

Address: nnsc.nsf.net (128.89.1.178) 
e West Coast (US): 

Address: ftp.nisc.sri.com (192.33.33.22) 
e Pacific Rim: 

Address: munnari.oz.au (128.250.1.21) 
e Europe: 

Address: nic.nordu.net (192.36.148.17) 


Internet-Drafts are also available by e-mail. Send a message to: 
mail-server@nisc.sri.com. In the body type: 


“SEND internet-drafts/draft-ietf-osids-simple-stack-00.txt” or 
“SEND internet-drafts/draft-ietf-osids-simple-stack-00.ps” 


For questions, please mail to: internet-drafts@nri.reston.va.us. 


Getting Request for Comments (RFCs) 


Having told you how to obtain Internet-Drafts, we should quickly add 
a note about Request for Comments (RFCs), the official Internet docu- 
ment series. RFCs can be obtained via anonymous FTP from a 
number of repositories including: 


NIC.DDN.MIL 

FTP. NISC. SRI. COM 
NIS.NSF.NET 
NISC.JVNG.NET 
VENERA.ISI.EDU 
WUARCHIVE.WUSTL.EDU 
INFO@SH.CS.NET 
sunic.sunet.se 
walhalla.informatik.uni-dortmund.de 
mcsun.eu.net 
funet.fi 
ugle.unit.no 

ftp .diku.dk 


Some of these sites provide an automatic “RFC by e-mail” service. 
Hardcopy versions of the RFCs can be purchased from the Network 
Information Systems Center at SRI International, send e-mail to 
nisc@nisc.sri.com or call 1-415-859-6387. For more details about 
how to obtain RFCs, see ConneXions, Volume 6, No. 1, January 1992. 
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Preliminary Announcement and Call for Papers 


The International Workshop on Modeling, Analysis and Simulation 
of Computer and Telecommunication Systems (MASCOTS ’93) will be 
held January 17—20, 1993 at the Hyatt Hotel, La Jolla, San Diego, 
California, USA. The workshop is part of the 1993 SCS Western Multi- 
conference on Computer Simulation and is sponsored by the SCS, 
IEEE TCSIM, and IEEE TCARCH. (ACM, IEEECS, IFIPWG, ORSA 
cooperation/sponsorships have been requested). 


The workshop is expected to be a major event where researchers, 
developers and experts with interests in systems design, modeling 
and analysis, simulation, performance evaluation and various appli- 
cations will meet to consider one of the current important themes: 
modeling, analysis and simulation of computer/communication sys- 
tems of the present and future. 


Performance, robustness and reliability predictions of computer and 
communication systems of future in particular are both important and 
extremely challenging. Modeling, analysis and simulation are widely 
applicable to problems in the specification and design of computer and 
communication systems; however, traditional modeling, analysis and 
simulation strategies need to be closely scrutinised for their robust- 
ness, efficiency and practical applicability in areas of future computer/ 
communication systems. Some techniques are evolving and new 
approaches are emerging to satisfy the requirements of these ever- 
expanding areas. 


Topics of interest include, but are not limited to: 
Modeling / Analysis / Simulation of Systems such as: 
e Multiple Processor Systems 
e High-Speed Computer Networks and Distributed Systems 
e Massively Parallel and Scalable Systems 
e Systolic structures and SIMD/Vector Machines 
e Fault Tolerant Systems 

Real-Time Systems 

Artificial Neural Networks 

° Parallel, VLSI and RISC/CISC architectures 

e Large, Distributed, (Incomplete) Data-base Systems 


e Application systems like DSP/AI applications and expert systems/ 
Vision and Image Processing Systems/Robotics and Control ete. 


e Complex and heterogeneous systems 

e Novel architectures/advances in technologies 

e Telecommunication/communication systems 

Advances in Modeling Techniques such as: 

e Analytic (Performance, Reliability and Performability) Modeling 


e Specification and validation techniques as in network protocols, 
logic design etc. 


e Discrete Simulation 
e Numeric Simulation and Visualization Techniques 
e Intelligent Simulation Techniques with Knowledge as the key 


continued on next page 
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Important dates 


Conference Chairs 


Announcement and Call for Papers (continued) 


Papers that deal with these themes, both methodological and specific 
case study-oriented, are solicited. We are especially interested in 
papers on innovative modeling and/or simulation techniques that are 
expected to survive the onslaught of technological advances and 
remain current for a reasonable period of time. 


The workshop will have prominent guest speakers, presentations of 
refereed papers, panel sessions, tool and poster presentations. In 
addition, there will be tutorials on introductory and advanced topics. 


All submissions will be reviewed. We shall provide blind referring. 
Put names, affiliations and addresses for correspondence (postal and 
electronic) of authors on a separate cover. Papers must not exceed 12 
double-spaced pages. Provide an abstract and 3-4 keywords. Authors 
of accepted papers will have to present their papers at the workshop. 
A best paper award will be made. 


A limited number of posters/short papers can also be admitted. For 
posters, an extended abstract of maximum 4 double-spaced pages 
must be submitted. Full-length papers and poster abstracts will 
appear in the proceedings to be published by the SCS. 


Proposals for tutorials must contain a brief description of the theme, 
target audience, proposed time duration and an outline of the present- 
ation. Panel proposals should be based on a current theme that can 
generate a lively discussion. A brief position statement from the each 
panelist of a panel will be included in the proceedings. 


A selected set of high-quality papers, tutorials, state-of-the-art and 
invited lectures (revised and enlarged) will be published as a hard 
cover book, by Kluwer Academic Publishers, shortly after the work- 
shop. Send four copies of your papers and posters to the Program 
Committee Chair, Jean Walrand at the address given below. Panel 
session proposals and proposals for tutorial, should be sent to the 
respective Chairs. Special session proposals should be directed to 
Kallol Bagchi, Technical Co-Chair. All other inquiries should be 
directed to the Publicity Chair. 


There will be a Tools Fair at MASCOTS’93. Tools accepted for 
presentation should be demonstrated on a computer system or shown 
on a video tape. All submissions on tools must contain the details of 
the necessary equipment. Send abstracts on tools to one of the Tools 
Fair Managers. Brief descriptions of selected tools including pictures 
(max. 1 double-spaced page) will also appear in the proceedings. 


June 30, 92: Special sessions proposals due 


July 15, 92: Deadline for submissions of papers/tutorial and 
panel proposals/tools 


Sept. 15, 92: Notification of acceptance 


Oct. 15,.92: Camera-ready copy due 
General Chair: Program Committee Chair: 
Dr. Herb Schwetman Prof. Jean Walrand 
MCC University of California 
3500 West Balcones Center Drive 267M Cory Hall 
Austin, TX 78759, USA Berkeley, CA 94720, USA 
Phone: +1 512-338-3428 +1 510-642-1529 
Fax. +1 512-338-3885 +1 510-643-8426 
E-mail: hds@mcc.com wlr@diva.berkeley.edu 


More information 


The Interoperability Report 


Technical Co-Chairs: 


Dr. Kallol Bagchi 
Aalborg University, 
Fredrick Bajers Vej 7 
DK-9220, Aalborg Ost 
DENMARK 
Phone. 
E-mail: 


+45 98 15 85 22 
kkb@iesd.auc.dk 


Tutorial Chair: 


Prof. Kishor Trivedi 
Duke University 
Durham NC 27706 
USA 
E-mail: kst@egr.duke.edu 


Publicity Chair: 


Dr. Patrick Dowd 

State University of New York 
Buffalo, NY 14260 

USA 

E-mail: dowd@eng.buffalo.edu 


Tools Fair Managers: 


Dr. Thomas Braunl 
IPVR 

University of Stuttgart, 
Breitwiesenstr. 20—22 
D-7000 Stuttgart 80, 
GERMANY 

E-mail: 


Dr. Doug DeGroot, MS 8435 
Texas Instruments 

6550 Chase Oaks Blvd. 
Plano, TX 75023 

USA 

+1 214 575 3763 
degroot@dog.dseg.ti.com 


Panel Chair: 


Prof. Dharma Agrawal, Box 7911 
North Carolina State University 
Raleigh, NC 27695-7911 

USA 
dpa@csl36h.csl.ncsu.edu 


Treasurer: 


Dr. Anup Kumar 

University of Louisville 
Louisville, KY 40292 

USA 
AOKUMAO1@ulkyvx.bitnet 


Dr. Manu Thapar 

HP Research Labs. 

Hewlett Packard Company 
1501 Page Mill Road 

Palo Alto, CA 94304 

USA 
thapar@hpl.hplabs.hp.com 


braunl@informatik.uni-stuttgart.de 


If you are interested in receiving further announcements of this 
workshop, please contact (preferably by e-mail): 


Dr. Kallol Bagchi 
Aalborg University 
Fredrick Bajers Vej 7 
DK-9220 Aalborg Øst 


DENMARK 

Phone: + 45 98 15 42 11, x4901 
Fax: + 45 98 15 67 40 
E-mail: kkb@iesd.auc.dk 


Dr. Patrick Dowd 
SUNY/Buffalo 

Bell Hall 

Buffalo, NY 14260 

USA 

+1 716 636-2406 

+1 716 636-3656 
dowd@eng.buffalo.edu 


Coming in future ConneXions: 


“The Guy with The Bike” 


“Prospero: A Virtual Directory Service for the Internet” 
“How to Win the Battle of Network Management” 

“A Summary of the WORLDWIDEWEB System” 
“Comparing Compound Document Architectures” 
“Multiprotocol Encapsulation over Frame Relay” 

“The OSF Distributed Management Environment (DME)” 


“The Internet Gopher” 
“OSI Conformance Testing” 


Special Issue: Electronic Mail and Directory Services 
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CONNEXIONS 


Format 


Topics 


Paper submissions 


Announcement and Call for Papers 


The Sixth USENIX System Administration Conference (LISA) will be 
held in Long Beach, California, October 19-23, 1992. 


The annual LISA conference provides a forum in which system ad- 
ministrators from a variety of sites can meet to share new ideas and 
experiences. A growing success for the past five years, LISA is the 
only conference which focuses specifically on the needs of system 
administrators. In previous years, LISA has targeted large instal- 
lations. However, this year we are extending the scope of LISA to 
include system administrators from all UNIX sites. 


A dual-track tutorial program will be offered during the first two days 
of the conference, followed by a three day technical conference. The 
tutorial program will address issues in introductory and advanced 
system administration. 


The program committee will be reviewing papers submitted on sub- 
jects including (but not limited to): 


¢ Tools for Real-Time System Troubleshooting 

e Remote/Off-site System Administration 

e Tricks in User Education 

e Graphical User Interfaces for System Administration 

e Distributed System Administration 

e Experiences Using Third-party Administration Software 
° Network Growth and Performance Management 

e How to Grow Your Own Junior System Administrators 
e Network Management 

Wireless LANs 

e System Security Monitoring 


e Evaluating Performance of High-End Workstations and Servers 
e Keys to Successful, Painless Upgrades 

e Object Management Systems for System Administration 

e Standardization of System Administration 

e Heterogeneous System Administration 

e System Archiving and Backups 


We are especially interested in papers which provide freely available 
or fully described solutions to existing problems. We are also looking 
for papers which, in some way, advance the state of the art. 


The committee requires that an extended abstract be submitted for 
the paper selection process [full-papers are not acceptable for this 
stage; if you send a full paper, you must also include an extended 
abstract for judging]. Your extended abstract should consist of a 
traditional abstract which summarizes the content/ideas of the entire 
paper, followed by a skeletal outline of the full paper. Final papers 
should be from 5 to 20 pages in length, including diagrams and 
figures. Papers should include a brief description of the site, an 
outline of the problem and issues, and a description of the solution. 
We require electronic form of the extended abstract; we require both 
hardcopy and electronic (nroff/troff or ASCID form of the final paper. 


Proceedings 


BOFs, etc. 


Important dates 


Contact information 


Program Committee 


Topics 


Submitting papers 


The Interoperability Report 


Conference proceedings will be distributed to all the attendees and 
also will be available after the conference from the USENIX Associ- 
ation. 


In addition to tutorials and regular technical sessions, a handful of 
other events will be included as part of the program. For example, the 
program may include special panels, work-in-progress reports, birds- 
of-a-feather (BOF) sessions, and invited talks. The program com- 
mittee invites you to submit informal proposals, ideas, or suggestions 
you might have on any of these topics. 


Extended Abstract Deadline: June 29,1992 

Acceptance Notification: July 20, 1992 

Final Papers Received: August 31, 1992 

Submit electronic copy of extended abstracts (preferably by electronic 


mail) to: 


Trent Hein 

XOR Computer Systems 
2525 Arapahoe, Suite E4-264 
Boulder, Colorado 80302 
Phone: 303- 440-6093 
E-mail: trent@xor.com 


Trent Hein (Program Chair) XOR Computer Systems 


Rik Farrow UNIX World 
Jeff Forys University of Utah 
John Hardt Martin Marietta Astronautics 
Rob Kolstad (Board Liaison) Berkeley Software Design, Inc. 
Herb Morreale XOR Computer Systems 
Pat Parseghian AT&T Bell Laboratories 
Jeff Polk Sun Microsystems 
Call For Anthology Papers 


I am seeking papers for a book on networking in less developed 
nations. The tentative title is “Toward a Truly Global Network.” 


The anthology will be broad, encompassing descriptions of networks, 
technology, applications, and social, economic and political consider- 
ations and implications. It will include papers on what is currently 
happening and visions of the future. The primary intended readers 
are people now working in the area and those who might like to begin 
doing so. An appendix will refer readers to resources and projects, and 
it will be assumed that authors and readers are on the Net. Previ- 
ously published, revised or original papers are suitable. 


If you are interested in publishing a paper in this anthology, please 
let me know, sending your tentative title, an abstract or short outline, 
and an estimate of the length. If the paper has been published previ- 
ously, please send the full text. Send your titles and/or papers to: 


Professor Larry Press 

CSUDH 

10726 Esther Avenue 

Los Angeles, CA 90064 

Phone: +1 310-475-6515 

Fax: +1 310-516-3664 

Internet: lpress@venera.isi.edu 
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Sponsors 


Focus 


Topics 


Submissions 


Call for Participation 


The Third International Symposium on Integrated Network Manage- 
ment (ISINM ‘93) will be held April 4-9, 1993 at the historic Sheraton 
Palace Hotel in San Francisco, California. 


Subtitled “Strategies for the Nineties,” The symposium is sponsored by 
the International Federation for Information Processing (IFIP) Work- 
ing Group 6.6 on Network Management for Communication Networks, 
with participation by the IEEE Communications Society Technical 
Committee on Network Operations and Management (CNOM) and 
support from the Institute for Educational Services (IES). 


The Third International Symposium on Integrated Network Manage- 
ment will build on the success of ISINM ’89 and ISINM ’91 in forming 
a central technical forum for the research, standards, development, 
systems integrator, vendor and user communities of network manage- 
ment. The second symposium demonstrated an increasing interest in 
overall management solutions across all types of networks, enterprise 
communication systems, telecommunications, distributed computing 
systems and applications. Such comprehensive management is thus 
the focus of the third symposium. This focus includes all aspects of the 
network, integrating data and telecommunications—from narrowband 
to broadband, terrestrial to satellite, and stationary to mobile used for 
ordinary as well as advanced multi-media communications. 


Authors are invited to submit unpublished papers, as well as propo- 
sals for tutorial and panel discussions in the following topic areas: 

e Standards, Layer Management Approaches, OSI, TMN, Internet, etc. 
e Models and Architecture 

e Fault, Performance, Configuration, Security & Accounting Mgmt. 

e Management Protocols and Protocol Management 

e Interoperability and Cooperative Operation 

e Telecommunications Management including OAM&P 

e Quality of Service Management 

e Broadband and Mobile Communications Impacts 

e User Requirements and Analysis for Integrated Systems Mgmt. 

e Case Study Experiences: Solutions, Limitations and Challenges 

e Users’ Perspectives and Needs 

e Modeling & Storage: Database Techniques, Object Oriented Mgmt. 

e Information Interpretation: AI Techniques, Rule-Based Mgmt. 

e Neural-Networks Modeling 

e Interplay of Distributed Systems and Telecommunications Mgmt. 

e Application and Distributed Systems Management 

e Formal Methods 


Please submit seven (7) copies of complete papers in English to either 
address listed below. The cover page must contain the paper title, 
brief abstract, list of keywords, author(s) full name(s), affiliation(s), 
complete address(es), telephone number(s), and (optionally) electronic 
mail address(es). All submissions will be carefully reviewed and 
returned to the authors with comments by renowned experts and the 
Program Committee to ensure high quality. The authors of accepted 
papers will receive suggested modifications for inclusion in the widely 
distributed hardbound Symposium Proceedings. 


The Interoperability Report 


Important dates 


Vendor Program 


More information 


Send complete papers, as well as proposals for tutorials and panel 
discussions to either: 


Yechiam Yemini 

Program Co-Chair (Americas, Australia) 
Columbia University 

450 Computer Science Building 

New York, NY 10027 

USA 


or: 


Heinz-Gerd Hegering 

Program Co-Chair (Europe, Asia, Africa) 
University of Munich 

Institut fiir Informatik—LRZ 

Barer Straße 21 

D-8000 Miinchen 2 

GERMANY 


Deadline for receipt of papers: July 1, 1992 


Deadline for receipt of proposals 
for tutorials and panel discussions: July 1, 1992 


Notification of Acceptance mailed: November 1, 1992 


Final camera-ready papers due: December 1, 1992 


The Third International Symposium on Integrated Network Manage- 
ment offers vendors the opportunity to demonstrate their manage- 
ment products for the integrated network management community. 
Please call +1 415-512-1316 for more information on how your com- 
pany can participate in the ISINM ’93 Vendor Program. 


For further information about the symposium contact: 


ISINM 793 

P.O. Box 191885 

San Francisco, CA 94119-1885 
Phone: +1 415-512-1316 

Fax: +1 415-512-1325 

E-mail: 4367585@mcimail.com 


NTEROE? 


26-30 EL 1992 © Moscone Center ¢ San Francisco, CA 


L ia 


Call 1-800-INTEROP for more information or to register. 
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